Net.rtl CPU usage?

QNX Newsgroups (Archives) qdn.public.qnx4
#1

Hi,
I’ve been using Net.rtl for a bit, and noticed some issues with CPU usage.
I know that the chipset that I’m using doesn’t implement most of the
features that other chipsets use, so the driver does more work. But I found
that if I unplug the ethernet cable while the driver is running, momentary
“pauses” occur in my application (graphics moving around a bit suddenly stop
for a moment, then move again). When the cable is plugged in again (with an
active link) it works fine.

Anything I might do to avoid the “pauses”? Also, any chance the Net.rtl
code might be able to handle something differently to avoid the “pausing”?

TIA!
R B Adler

#2

Previously, R B Adler wrote in qdn.public.qnx4:

Hi,
I’ve been using Net.rtl for a bit, and noticed some issues with CPU usage.
I know that the chipset that I’m using doesn’t implement most of the
features that other chipsets use, so the driver does more work. But I found
that if I unplug the ethernet cable while the driver is running, momentary
“pauses” occur in my application (graphics moving around a bit suddenly stop
for a moment, then move again). When the cable is plugged in again (with an
active link) it works fine.

Anything I might do to avoid the “pauses”? Also, any chance the Net.rtl
code might be able to handle something differently to avoid the “pausing”?

Yes, don’t unplug the cable! :slight_smile: I’ll e-mail you an updated driver.

Hugh.

TIA!
R B Adler

#3

Hugh,
The email address associated with my posts is non-existant, so if you try to
send to it you will probably get rejected (mapson is nospam backwards).

You can send it to cococr@cs.rpi.edu

One more issue I’ve come across. The particular Ethernet card we use (that
uses the Net.rtl driver) has some weird issue that doesn’t occur very often,
but it does happen. 2 of our customers successfully reproduced it a few
times. Somehow, the PCI Vendor ID changed on the card. We test our units
before they go out the door, and they all show proper values. When they
hook up the unit to their network, the vendor ID changes. I’ve contacted
the card’s manufacturer and they have no idea how it might change. The
problem I have is that Net.rtl no longer recognizes the card natively (I
could pass the vendor/device ID as the parameter, but would require a lot of
research through my code to make sure it works smoothly). What I did was
use a hex editor to change Net.rtl. I found the vendor/device ID pairs hex
values for another card that Net.rtl supports, and changed them to the
values I’m getting. This is only a temporary hack hopefully, as I don’t
want to change them continuously. Is it possible to get another
vendor/device pair added to Net.rtl? :slight_smile:


“Hugh Brown” <hsbrown@qnx.com> wrote in message
news:Voyager.010528082515.7366A@node90.ott.qnx.com…

Previously, R B Adler wrote in qdn.public.qnx4:
Hi,
I’ve been using Net.rtl for a bit, and noticed some issues with CPU
usage.
I know that the chipset that I’m using doesn’t implement most of the
features that other chipsets use, so the driver does more work. But I
found
that if I unplug the ethernet cable while the driver is running,
momentary
“pauses” occur in my application (graphics moving around a bit suddenly
stop
for a moment, then move again). When the cable is plugged in again
(with an
active link) it works fine.

Anything I might do to avoid the “pauses”? Also, any chance the Net.rtl
code might be able to handle something differently to avoid the
“pausing”?


Yes, don’t unplug the cable! > :slight_smile: > I’ll e-mail you an updated driver.

Hugh.

TIA!
R B Adler
\

#4

Previously, R B Adler wrote in qdn.public.qnx4:

Hugh,
The email address associated with my posts is non-existant, so if you try to
send to it you will probably get rejected (mapson is nospam backwards).

You can send it to > cococr@cs.rpi.edu

I will forward the driver to this address.

One more issue I’ve come across. The particular Ethernet card we use (that
uses the Net.rtl driver) has some weird issue that doesn’t occur very often,
but it does happen. 2 of our customers successfully reproduced it a few
times. Somehow, the PCI Vendor ID changed on the card. We test our units
before they go out the door, and they all show proper values. When they
hook up the unit to their network, the vendor ID changes. I’ve contacted
the card’s manufacturer and they have no idea how it might change. The
problem I have is that Net.rtl no longer recognizes the card natively (I
could pass the vendor/device ID as the parameter, but would require a lot of
research through my code to make sure it works smoothly). What I did was
use a hex editor to change Net.rtl. I found the vendor/device ID pairs hex
values for another card that Net.rtl supports, and changed them to the
values I’m getting. This is only a temporary hack hopefully, as I don’t
want to change them continuously. Is it possible to get another
vendor/device pair added to Net.rtl? > :slight_smile:

Why is the vendor/device pair changing? You can specify a vendor and device
on the command line with the -x and -y parameters.


“Hugh Brown” <> hsbrown@qnx.com> > wrote in message
news:> Voyager.010528082515.7366A@node90.ott.qnx.com> …
Previously, R B Adler wrote in qdn.public.qnx4:
Hi,
I’ve been using Net.rtl for a bit, and noticed some issues with CPU
usage.
I know that the chipset that I’m using doesn’t implement most of the
features that other chipsets use, so the driver does more work. But I
found
that if I unplug the ethernet cable while the driver is running,
momentary
“pauses” occur in my application (graphics moving around a bit suddenly
stop
for a moment, then move again). When the cable is plugged in again
(with an
active link) it works fine.

Anything I might do to avoid the “pauses”? Also, any chance the Net.rtl
code might be able to handle something differently to avoid the
“pausing”?


Yes, don’t unplug the cable! > :slight_smile: > I’ll e-mail you an updated driver.

Hugh.

TIA!
R B Adler



\

#5

Oh Well. There goes any hope of being spam proof.

\

Bill Caroselli - Sattel Global Networks
1-818-709-6201 ext 122



“Hugh Brown” <hsbrown@qnx.com> wrote in message
news:Voyager.010529150504.2537B@node90.ott.qnx.com…

Previously, R B Adler wrote in qdn.public.qnx4:
Hugh,
The email address associated with my posts is non-existant, so if you
try to
send to it you will probably get rejected (mapson is nospam backwards).

You can send it to > MAPSON@cs.rpi.edu


I will forward the driver to this address.

#6

In article <9f0mle$7hh$1@inn.qnx.com>, request@mapson.com says…

One more issue I’ve come across. The particular Ethernet card we use (that
uses the Net.rtl driver) has some weird issue that doesn’t occur very often,
but it does happen. 2 of our customers successfully reproduced it a few
times. Somehow, the PCI Vendor ID changed on the card. We test our units
before they go out the door, and they all show proper values. When they
hook up the unit to their network, the vendor ID changes. I’ve contacted
the card’s manufacturer and they have no idea how it might change. The
problem I have is that Net.rtl no longer recognizes the card natively (I
could pass the vendor/device ID as the parameter, but would require a lot of
research through my code to make sure it works smoothly). What I did was
use a hex editor to change Net.rtl. I found the vendor/device ID pairs hex
values for another card that Net.rtl supports, and changed them to the
values I’m getting. This is only a temporary hack hopefully, as I don’t
want to change them continuously. Is it possible to get another
vendor/device pair added to Net.rtl? > :slight_smile:
The Vendor/Device ID can change if (somehow) the contents of the EEPROM

(usually a 9346) that is on the card are changed.
This is not usually very easy to do, but some programs that are intended
to do software configuration of these cards (like our boot configuration
program) could if improperly used, or if there are bugs in them, write
the wrong values to the wrong locations in the EEPROM.
Primary candidate for this type of problem: Having a driver actually
running and working with the card while one is attempting to also
configure the card in a manner that changes the EEPROM contents.
Most of the Realtek chips pick up a number of configuration items from
the EEPROM at reset time, and this could also have a bearing on what you
are seeing. (For e.g. doc for the RTL8029AS says something like this:
If the 8029ASID field (locations 0x76,0x77) do not have the value 0x8029
in them, then the chip will not act as an 8029AS, instead it will act as
if it was a 8029 (no AS) and if you are attempting to use the new
features defined by the 8029AS, they will not be available)

\

Stephen Munnings
Software Developer
Corman Technologies Inc.

#7

DOH!

I actually don’t care, I should change my addy since that email address is
spam-capable already…



“Bill Caroselli” <Bill@Sattel.com> wrote in message
news:9f0t5b$bpi$1@inn.qnx.com…

Oh Well. There goes any hope of being spam proof.

\

Bill Caroselli - Sattel Global Networks
1-818-709-6201 ext 122



“Hugh Brown” <> hsbrown@qnx.com> > wrote in message
news:> Voyager.010529150504.2537B@node90.ott.qnx.com> …
Previously, R B Adler wrote in qdn.public.qnx4:
Hugh,
The email address associated with my posts is non-existant, so if you
try to
send to it you will probably get rejected (mapson is nospam
backwards).

You can send it to > MAPSON@cs.rpi.edu


I will forward the driver to this address.