en convertor and rx errors

Hi again :wink:

This time, I would like to know what an ethernet convertor is supposed to
do…
In the DDK docs, it says that the convertor has to insert the 14 bytes of
the ethernet header…
I guess it’s 6 bytes for the source address, 6 for the destination address
and two for the the data lenght…

For the rest of the ethernet frame : preamble , start of frame delimiter ,
pad and checksum.
The device driver does this work for us?

I asked me this question because when I send 1000000 times the same frame
from a thread in a down producer , the nicinfo tells me that 1000000 packets
were sent without errors but the nicinfo of the receiver tells me that there
was only 34033 rx packets ok… And 2052 rx errors…
( I did the test several times and it’s always the same)

Where could these errors come from?
Is it a problem of buffer or something?

I send the packets from a pentium 2 350Mhz to a pentium 3
1.13GiHz…
I use the devn-via-rhine.so driver for the p2(sender) and the devn-rtl.so
for the p3(receiver)…(Is it possible to see the code of these drivers??)


I did the test with tcp/ip and ,in this case, everything works fine… Maybe
because it takes 60 seconds to send the 1000000 packets…

Thanks a lot to everybody who can help me :slight_smile:

Arnaud Stoumont
(sorry for my English…)

Yes, all the new NIC drivers insert the checksum ,Preamble etc. The Packet
loss could be attributed to limited buffer space available in the
receiver.Most of the Cards I know do well in transmitting but are lousy
when receiving the packets.To confirm that you might have to use a network
sniffer.Check out the number of receive descriptors in the driver.Increasing
the number of receive descriptors might improve the performance.

Sreekanth

“arno stoum” <starn@yucom.be> wrote in message
news:ac685n$fra$1@inn.qnx.com

Hi again > :wink:

This time, I would like to know what an ethernet convertor is supposed to
do…
In the DDK docs, it says that the convertor has to insert the 14 bytes of
the ethernet header…
I guess it’s 6 bytes for the source address, 6 for the destination address
and two for the the data lenght…

For the rest of the ethernet frame : preamble , start of frame delimiter ,
pad and checksum.
The device driver does this work for us?

I asked me this question because when I send 1000000 times the same frame
from a thread in a down producer , the nicinfo tells me that 1000000
packets
were sent without errors but the nicinfo of the receiver tells me that
there
was only 34033 rx packets ok… And 2052 rx errors…
( I did the test several times and it’s always the same)

Where could these errors come from?
Is it a problem of buffer or something?

I send the packets from a pentium 2 350Mhz to a pentium 3
1.13GiHz…
I use the devn-via-rhine.so driver for the p2(sender) and the devn-rtl.so
for the p3(receiver)…(Is it possible to see the code of these drivers??)


I did the test with tcp/ip and ,in this case, everything works fine…
Maybe
because it takes 60 seconds to send the 1000000 packets…

Thanks a lot to everybody who can help me > :slight_smile:

Arnaud Stoumont
(sorry for my English…)

Hi Sreekanth,

Thank you again for your answer :slight_smile:

To change the number of receive descriptors , is there an other way than to
change the C source codes of the driver?
I can’t find the source code for the devn-rtl.so …

One last thing (stupid but very annoying) : for example, when you do
“pci -v” in the terminal, a lot of informations come on the screen but it’s
not possible to see everything due to the size of the window… What is the
equivalent command to the dos command : dir /p ?? (pci -v /p won’t
work…)


Thanks a lot,

Arnaud Stoumont

pci -v | less

chris


arno stoum <starn@yucom.be> wrote:

Hi Sreekanth,

Thank you again for your answer > :slight_smile:

To change the number of receive descriptors , is there an other way than to
change the C source codes of the driver?
I can’t find the source code for the devn-rtl.so …

One last thing (stupid but very annoying) : for example, when you do
“pci -v” in the terminal, a lot of informations come on the screen but it’s
not possible to see everything due to the size of the window… What is the
equivalent command to the dos command : dir /p ?? (pci -v /p won’t
work…)


Thanks a lot,

Arnaud Stoumont


Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

You need not have the source code.When mounting the driver for your card
use -o to specify the options.for e,g,g
mount -T io-net -o transmit =300 devn-via-rhine.so.This makes the number of
transmit descriptors to 300.For all the options type use /lib/dll/your
driver.so For the next question pci -v|more can be used.

Hope that helps

Sreekanth

“arno stoum” <starn@yucom.be> wrote in message
news:ac875o$r4f$1@inn.qnx.com

Hi Sreekanth,

Thank you again for your answer > :slight_smile:

To change the number of receive descriptors , is there an other way than
to
change the C source codes of the driver?
I can’t find the source code for the devn-rtl.so …

One last thing (stupid but very annoying) : for example, when you do
“pci -v” in the terminal, a lot of informations come on the screen but
it’s
not possible to see everything due to the size of the window… What is
the
equivalent command to the dos command : dir /p ?? (pci -v /p won’t
work…)


Thanks a lot,

Arnaud Stoumont

Thanks a lot Sreekanth and Chris,

I think rx descriptors is one of the problems but it’s not the only one…
I tried different numbers : 10 , 100, 1000 , 200, 300 and I found that the
best was with 200 with 75000 rx packets ok (far from 1000000 but better than
15000 with the default rx descriptors number (just to know, what is the
default number??))
But the second time with 200, everything is different…

I’ve noticed that the blue line of the system monitor (which indicate the
network performance(I think…))was :

  1. for the sender : 850% … (but nicinfo tells no problem…)
  2. for the receiver : it is full for 2 or 3 seconds and then drops to zero
    (and it seems that there is nothing received anymore but the sender is still
    at 850%…)

Maybe I do something wrong…
here is what I do:

\

slay io-net

io-net &

[1] 1708049

mount -T io-net -o receive=200 devn-rtl.so

[1] + Done io-net

mount -T io-net /home/drivers/ncm-conv_en_raw.so

mount -T io-net /home/drivers/raw_recv.so

nicinfo

RealTek 8139 Ethernet Controller
Physical Node ID … 00E018 2DDA28
Current Physical Node ID … 00E018 2DDA28
Media Rate … 100.00 Mb/s half-duplex UTP
MTU … 1514
Lan … 0
I/O Port Range … 0xB000 → 0xB0FF
Hardware Interrupt … 0x9
Promiscuous … Disabled
Multicast … Enabled

Total Packets Txd OK … 0
Total Packets Txd Bad … 0
Total Packets Rxd OK … 16708
Total Rx Errors … 941

Total Bytes Txd … 0
Total Bytes Rxd … 1002480

Tx Collision Errors … 0
Tx Collisions Errors (aborted) … 0
Carrier Sense Lost on Tx … 0
FIFO Underruns During Tx … 0
Tx deferred … 0
Out of Window Collisions … 0
FIFO Overruns During Rx … 0
Alignment errors … 0
CRC errors … 0

Thank you to anybody who got an other good idea…

Arnaud Stoumont

Looks like you have connected your machines through a hub(I see that the
duplex mode is half duplex).This can seriously hurt the performance.Try
using a switch between the machines or use a cross-over cable

Sreekanth

“arno stoum” <starn@yucom.be> wrote in message
news:acblqr$c76$1@inn.qnx.com

Thanks a lot Sreekanth and Chris,

I think rx descriptors is one of the problems but it’s not the only one…
I tried different numbers : 10 , 100, 1000 , 200, 300 and I found that
the
best was with 200 with 75000 rx packets ok (far from 1000000 but better
than
15000 with the default rx descriptors number (just to know, what is the
default number??))
But the second time with 200, everything is different…

I’ve noticed that the blue line of the system monitor (which indicate the
network performance(I think…))was :

  1. for the sender : 850% … (but nicinfo tells no problem…)
  2. for the receiver : it is full for 2 or 3 seconds and then drops to zero
    (and it seems that there is nothing received anymore but the sender is
    still
    at 850%…)

Maybe I do something wrong…
here is what I do:

\

slay io-net

io-net &

[1] 1708049

mount -T io-net -o receive=200 devn-rtl.so

[1] + Done io-net

mount -T io-net /home/drivers/ncm-conv_en_raw.so

mount -T io-net /home/drivers/raw_recv.so

nicinfo

RealTek 8139 Ethernet Controller
Physical Node ID … 00E018 2DDA28
Current Physical Node ID … 00E018 2DDA28
Media Rate … 100.00 Mb/s half-duplex UTP
MTU … 1514
Lan … 0
I/O Port Range … 0xB000 → 0xB0FF
Hardware Interrupt … 0x9
Promiscuous … Disabled
Multicast … Enabled

Total Packets Txd OK … 0
Total Packets Txd Bad … 0
Total Packets Rxd OK … 16708
Total Rx Errors … 941

Total Bytes Txd … 0
Total Bytes Rxd … 1002480

Tx Collision Errors … 0
Tx Collisions Errors (aborted) … 0
Carrier Sense Lost on Tx … 0
FIFO Underruns During Tx … 0
Tx deferred … 0
Out of Window Collisions … 0
FIFO Overruns During Rx … 0
Alignment errors … 0
CRC errors … 0

Thank you to anybody who got an other good idea…

Arnaud Stoumont

Well, I got a cross-over cable but I didn’t think that the fact that it
wasn’t full duplex was a problem because only the sender is supposed to
talk…In the nicinfo of the sender, there isn’t any byte received…
I’ll try with full duplex. But if it works I’ll have to ask me some other
questions!!! :wink:

Thank a lot Sreekanth for your support :slight_smile:

Arnaud Stoumont

Other problem :

I had no problem to set the “receiver” driver to 100Mb full-duplex.

But for the “sender”, even with “duplex=1” , nicinfo still says it’s
half-duplex…
I tried with an other card (but same type: Dlink DFE-530TX normaly supported
by QNX) and it’s the same …

I don’t think it’s a cable problem…
On my Dlink network card, there are three lights: link , 100Mb and full. The
three lights are lit.
It’s supposed to mean it’s 100Mb full-duplex… (maybe it is only some
possibility, not the real choices of transmission…)

Thanks a lot,

Arnaud Stoumont