public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Re: ne2k-pci uncorrectly detecting collisions ?
  2004-05-05 12:35 ne2k-pci uncorrectly detecting collisions ? Lucas Nussbaum
@ 2004-05-04 12:55 ` backblue
  2004-05-05 13:00 ` Richard B. Johnson
  1 sibling, 0 replies; 6+ messages in thread
From: backblue @ 2004-05-04 12:55 UTC (permalink / raw)
  To: Lucas Nussbaum, linux-kernel

I think that problem, it's because hardware, ne2k-pci NIC's and all realtek stuff, are chip NIC's that it's not suposed to use in that way, i have many problems like that, with realtek NIC's, but when i used real NIC's like 3com, you dont have any problems at all!
The realtek's NIC's starts complaining because another ones, they dont live well together! :)
Buy 3com nic's. :)

good luck

On Wed, 5 May 2004 14:35:32 +0200
Lucas Nussbaum <lucas@lucas-nussbaum.net> wrote:

> Hello,
> 
> I have experienced problem with the ne2k-pci driver. The symptoms were
> extremly poor performance with TCP. After some investigations, I believe
> it might be caused by problems with detecting collisions.
> 
> I tested with 3 cards :
> - eth1 : RTL8029 - not working properly
>   the chip says RTL8029, but lspci says RTL8029(AS)
> - eth2 : RTL8029AS - working.
> - eth3 : RTL8029AS - not working properly
> lspci for all three cards :
> 00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd.  RTL-8029(AS)
> 
> The same problem was experienced on FreeBSD, but it hurts a lot to say
> that there wasn't any problem when I tested under Windows - so it's
> probably not a broken card problem.
> 
> All 3 NICs were in the same box, using the same ne2k-pci driver compiled
> as a module (kernel version is 2.4.24). They used the same 10/100 Hub to
> talk to the same NIC on the other end. Traffic on the network during the
> test was quite low but not nonexistent.
> 
> As you can see :
> - throughput for eth1 and eth3 with TCP is extremly low.
> - throughput with UDP is normal.
> - eth1 and eth3 saw no collisions, but eth2 saw a lot.
> - eth1 and eth3 saw lots of frame errors, but eth2 saw much less.
>  
> Here are the detailed test results. I can provide more results if needed.
> + ifconfig eth1 down
> + ifconfig eth2 down
> + ifconfig eth3 down
> + rmmod ne2k-pci
> + modprobe ne2k-pci
> + ifconfig eth1 172.36.1.2
> + ifconfig eth2 172.37.1.2
> + ifconfig eth3 172.38.1.2
> + netperf -H 172.36.1.1 -l 20
> TCP STREAM TEST to 172.36.1.1
> Recv   Send    Send                          
> Socket Socket  Message  Elapsed              
> Size   Size    Size     Time     Throughput  
> bytes  bytes   bytes    secs.    10^6bits/sec  
> 
>  87380  16384  16384    20.18       0.59   
> + netperf -H 172.37.1.1 -l 20
> TCP STREAM TEST to 172.37.1.1
> Recv   Send    Send                          
> Socket Socket  Message  Elapsed              
> Size   Size    Size     Time     Throughput  
> bytes  bytes   bytes    secs.    10^6bits/sec  
> 
>  87380  16384  16384    20.04       8.54   
> + netperf -H 172.38.1.1 -l 20
> TCP STREAM TEST to 172.38.1.1
> Recv   Send    Send                          
> Socket Socket  Message  Elapsed              
> Size   Size    Size     Time     Throughput  
> bytes  bytes   bytes    secs.    10^6bits/sec  
> 
>  87380  16384  16384    20.05       0.56   
> + netperf -t UDP_STREAM -H 172.36.1.1 -l 20 -- -m 1472
> UDP UNIDIRECTIONAL SEND TEST to 172.36.1.1
> Socket  Message  Elapsed      Messages                
> Size    Size     Time         Okay Errors   Throughput
> bytes   bytes    secs            #      #   10^6bits/sec
> 
>  65535    1472   20.00       16027      0       9.44
>  65535           20.00       15216              8.96
> 
> + netperf -t UDP_STREAM -H 172.37.1.1 -l 20 -- -m 1472
> UDP UNIDIRECTIONAL SEND TEST to 172.37.1.1
> Socket  Message  Elapsed      Messages                
> Size    Size     Time         Okay Errors   Throughput
> bytes   bytes    secs            #      #   10^6bits/sec
> 
>  65535    1472   19.99       15326      0       9.03
>  65535           19.99       15326              9.03
> 
> + netperf -t UDP_STREAM -H 172.38.1.1 -l 20 -- -m 1472
> UDP UNIDIRECTIONAL SEND TEST to 172.38.1.1
> Socket  Message  Elapsed      Messages                
> Size    Size     Time         Okay Errors   Throughput
> bytes   bytes    secs            #      #   10^6bits/sec
> 
>  65535    1472   20.00       16008      0       9.43
>  65535           20.00       15593              9.18
> 
> + netstat -i
> Table d'interfaces noyau
> Iface   MTU Met   RX-OK RX-ERR RX-DRP RX-OVR   TX-OK TX-ERR TX-DRP TX-OVR Flg
> eth0   1500 0    140926      0      0      0  232637      0      0      0 BMRU
> eth1   1500 0      1049      0      0      0   17292      0      0      0 BMRU
> eth2   1500 0      7421      0      0      0   30134      0      0      0 BMRU
> eth3   1500 0       982      0      0      0   17201      0      0      0 BMRU
> lo    16436 0     22831      0      0      0   22831      0      0      0 LRU
> + ifconfig eth1
> eth1      Lien encap:Ethernet  HWaddr 00:00:E8:D7:E9:46  
>           inet adr:172.36.1.2  Bcast:172.36.255.255  Masque:255.255.0.0
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:1049 errors:0 dropped:0 overruns:0 frame:165
>           TX packets:17292 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 lg file transmission:1000 
>           RX bytes:75796 (74.0 KiB)  TX bytes:26148738 (24.9 MiB)
>           Interruption:5 Adresse de base:0xd800 
> 
> + ifconfig eth2
> eth2      Lien encap:Ethernet  HWaddr 00:E0:7D:75:C2:D7  
>           inet adr:172.37.1.2  Bcast:172.37.255.255  Masque:255.255.0.0
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:7421 errors:0 dropped:0 overruns:0 frame:27
>           TX packets:30134 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:225 lg file transmission:1000 
>           RX bytes:491544 (480.0 KiB)  TX bytes:45590838 (43.4 MiB)
>           Interruption:9 Adresse de base:0xdc00 
> 
> + ifconfig eth3
> eth3      Lien encap:Ethernet  HWaddr 00:00:E8:74:0E:1A  
>           inet adr:172.38.1.2  Bcast:172.38.255.255  Masque:255.255.0.0
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:982 errors:0 dropped:0 overruns:0 frame:147
>           TX packets:17201 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 lg file transmission:1000 
>           RX bytes:71062 (69.3 KiB)  TX bytes:26010052 (24.8 MiB)
>           Interruption:11 Adresse de base:0xe000 
> 
> Thank you,
> -- 
> | Lucas Nussbaum
> | lucas@lucas-nussbaum.net    lnu@gnu.org    GPG: 1024D/023B3F4F |
> | jabber: lucas@linux.ensimag.fr   http://www.lucas-nussbaum.net |
> | fingerprint: 075D 010B 80C3 AC68 BD4F B328 DA19 6237 023B 3F4F |
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* ne2k-pci uncorrectly detecting collisions ?
@ 2004-05-05 12:35 Lucas Nussbaum
  2004-05-04 12:55 ` backblue
  2004-05-05 13:00 ` Richard B. Johnson
  0 siblings, 2 replies; 6+ messages in thread
From: Lucas Nussbaum @ 2004-05-05 12:35 UTC (permalink / raw)
  To: linux-kernel

Hello,

I have experienced problem with the ne2k-pci driver. The symptoms were
extremly poor performance with TCP. After some investigations, I believe
it might be caused by problems with detecting collisions.

I tested with 3 cards :
- eth1 : RTL8029 - not working properly
  the chip says RTL8029, but lspci says RTL8029(AS)
- eth2 : RTL8029AS - working.
- eth3 : RTL8029AS - not working properly
lspci for all three cards :
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd.  RTL-8029(AS)

The same problem was experienced on FreeBSD, but it hurts a lot to say
that there wasn't any problem when I tested under Windows - so it's
probably not a broken card problem.

All 3 NICs were in the same box, using the same ne2k-pci driver compiled
as a module (kernel version is 2.4.24). They used the same 10/100 Hub to
talk to the same NIC on the other end. Traffic on the network during the
test was quite low but not nonexistent.

As you can see :
- throughput for eth1 and eth3 with TCP is extremly low.
- throughput with UDP is normal.
- eth1 and eth3 saw no collisions, but eth2 saw a lot.
- eth1 and eth3 saw lots of frame errors, but eth2 saw much less.
 
Here are the detailed test results. I can provide more results if needed.
+ ifconfig eth1 down
+ ifconfig eth2 down
+ ifconfig eth3 down
+ rmmod ne2k-pci
+ modprobe ne2k-pci
+ ifconfig eth1 172.36.1.2
+ ifconfig eth2 172.37.1.2
+ ifconfig eth3 172.38.1.2
+ netperf -H 172.36.1.1 -l 20
TCP STREAM TEST to 172.36.1.1
Recv   Send    Send                          
Socket Socket  Message  Elapsed              
Size   Size    Size     Time     Throughput  
bytes  bytes   bytes    secs.    10^6bits/sec  

 87380  16384  16384    20.18       0.59   
+ netperf -H 172.37.1.1 -l 20
TCP STREAM TEST to 172.37.1.1
Recv   Send    Send                          
Socket Socket  Message  Elapsed              
Size   Size    Size     Time     Throughput  
bytes  bytes   bytes    secs.    10^6bits/sec  

 87380  16384  16384    20.04       8.54   
+ netperf -H 172.38.1.1 -l 20
TCP STREAM TEST to 172.38.1.1
Recv   Send    Send                          
Socket Socket  Message  Elapsed              
Size   Size    Size     Time     Throughput  
bytes  bytes   bytes    secs.    10^6bits/sec  

 87380  16384  16384    20.05       0.56   
+ netperf -t UDP_STREAM -H 172.36.1.1 -l 20 -- -m 1472
UDP UNIDIRECTIONAL SEND TEST to 172.36.1.1
Socket  Message  Elapsed      Messages                
Size    Size     Time         Okay Errors   Throughput
bytes   bytes    secs            #      #   10^6bits/sec

 65535    1472   20.00       16027      0       9.44
 65535           20.00       15216              8.96

+ netperf -t UDP_STREAM -H 172.37.1.1 -l 20 -- -m 1472
UDP UNIDIRECTIONAL SEND TEST to 172.37.1.1
Socket  Message  Elapsed      Messages                
Size    Size     Time         Okay Errors   Throughput
bytes   bytes    secs            #      #   10^6bits/sec

 65535    1472   19.99       15326      0       9.03
 65535           19.99       15326              9.03

+ netperf -t UDP_STREAM -H 172.38.1.1 -l 20 -- -m 1472
UDP UNIDIRECTIONAL SEND TEST to 172.38.1.1
Socket  Message  Elapsed      Messages                
Size    Size     Time         Okay Errors   Throughput
bytes   bytes    secs            #      #   10^6bits/sec

 65535    1472   20.00       16008      0       9.43
 65535           20.00       15593              9.18

+ netstat -i
Table d'interfaces noyau
Iface   MTU Met   RX-OK RX-ERR RX-DRP RX-OVR   TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0   1500 0    140926      0      0      0  232637      0      0      0 BMRU
eth1   1500 0      1049      0      0      0   17292      0      0      0 BMRU
eth2   1500 0      7421      0      0      0   30134      0      0      0 BMRU
eth3   1500 0       982      0      0      0   17201      0      0      0 BMRU
lo    16436 0     22831      0      0      0   22831      0      0      0 LRU
+ ifconfig eth1
eth1      Lien encap:Ethernet  HWaddr 00:00:E8:D7:E9:46  
          inet adr:172.36.1.2  Bcast:172.36.255.255  Masque:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1049 errors:0 dropped:0 overruns:0 frame:165
          TX packets:17292 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000 
          RX bytes:75796 (74.0 KiB)  TX bytes:26148738 (24.9 MiB)
          Interruption:5 Adresse de base:0xd800 

+ ifconfig eth2
eth2      Lien encap:Ethernet  HWaddr 00:E0:7D:75:C2:D7  
          inet adr:172.37.1.2  Bcast:172.37.255.255  Masque:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:7421 errors:0 dropped:0 overruns:0 frame:27
          TX packets:30134 errors:0 dropped:0 overruns:0 carrier:0
          collisions:225 lg file transmission:1000 
          RX bytes:491544 (480.0 KiB)  TX bytes:45590838 (43.4 MiB)
          Interruption:9 Adresse de base:0xdc00 

+ ifconfig eth3
eth3      Lien encap:Ethernet  HWaddr 00:00:E8:74:0E:1A  
          inet adr:172.38.1.2  Bcast:172.38.255.255  Masque:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:982 errors:0 dropped:0 overruns:0 frame:147
          TX packets:17201 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000 
          RX bytes:71062 (69.3 KiB)  TX bytes:26010052 (24.8 MiB)
          Interruption:11 Adresse de base:0xe000 

Thank you,
-- 
| Lucas Nussbaum
| lucas@lucas-nussbaum.net    lnu@gnu.org    GPG: 1024D/023B3F4F |
| jabber: lucas@linux.ensimag.fr   http://www.lucas-nussbaum.net |
| fingerprint: 075D 010B 80C3 AC68 BD4F B328 DA19 6237 023B 3F4F |

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: ne2k-pci uncorrectly detecting collisions ?
  2004-05-05 12:35 ne2k-pci uncorrectly detecting collisions ? Lucas Nussbaum
  2004-05-04 12:55 ` backblue
@ 2004-05-05 13:00 ` Richard B. Johnson
  2004-05-05 13:10   ` Lucas Nussbaum
  1 sibling, 1 reply; 6+ messages in thread
From: Richard B. Johnson @ 2004-05-05 13:00 UTC (permalink / raw)
  To: Lucas Nussbaum; +Cc: linux-kernel

On Wed, 5 May 2004, Lucas Nussbaum wrote:

> Hello,
>
> I have experienced problem with the ne2k-pci driver. The symptoms were
> extremly poor performance with TCP. After some investigations, I believe
> it might be caused by problems with detecting collisions.
>

But software doesn't detect collisions. It just records what
hardware said it did. It looks like you have a 10 Mb/s card
on a 100 Mb/s network. The collisions reported are how the
hardware throttles the difference in physical-link speed.

It is possible that software didn't initialize a 100 Mb/s
device and instead initialized it to 10 Mb/s, but you
don't have any evidence of that presented.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5557.45 BogoMips).
            Note 96.31% of all statistics are fiction.



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: ne2k-pci uncorrectly detecting collisions ?
  2004-05-05 13:00 ` Richard B. Johnson
@ 2004-05-05 13:10   ` Lucas Nussbaum
  2004-05-05 19:45     ` Denis Vlasenko
  0 siblings, 1 reply; 6+ messages in thread
From: Lucas Nussbaum @ 2004-05-05 13:10 UTC (permalink / raw)
  To: Richard B. Johnson; +Cc: linux-kernel

On Wed, May 05, 2004 at 09:00:50AM -0400, "Richard B. Johnson" <root@chaos.analogic.com> wrote:
> > I have experienced problem with the ne2k-pci driver. The symptoms were
> > extremly poor performance with TCP. After some investigations, I believe
> > it might be caused by problems with detecting collisions.
> >
> 
> But software doesn't detect collisions. It just records what
> hardware said it did. It looks like you have a 10 Mb/s card
> on a 100 Mb/s network. The collisions reported are how the
> hardware throttles the difference in physical-link speed.

The hub is a 10/100 one, and the 3 RTL8029 are 10 Mbps only.

> It is possible that software didn't initialize a 100 Mb/s
> device and instead initialized it to 10 Mb/s, but you
> don't have any evidence of that presented.

No, because RTL8029 are 10 mbps only (they are BNC/RJ45 NICs).

But what I thought was that maybe, they were initialised as full duplex,
not half duplex. But again, I don't know where I can check that. I added
some printks and determined that the code used to init them full duplex
was never used. And there's no way to force them half duplex with this
driver.

Lucas

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: ne2k-pci uncorrectly detecting collisions ?
  2004-05-05 13:10   ` Lucas Nussbaum
@ 2004-05-05 19:45     ` Denis Vlasenko
  2004-05-06  9:52       ` Lucas Nussbaum
  0 siblings, 1 reply; 6+ messages in thread
From: Denis Vlasenko @ 2004-05-05 19:45 UTC (permalink / raw)
  To: Lucas Nussbaum, Richard B. Johnson; +Cc: linux-kernel

On Wednesday 05 May 2004 16:10, Lucas Nussbaum wrote:
> On Wed, May 05, 2004 at 09:00:50AM -0400, "Richard B. Johnson" <root@chaos.analogic.com> wrote:
> > > I have experienced problem with the ne2k-pci driver. The symptoms were
> > > extremly poor performance with TCP. After some investigations, I
> > > believe it might be caused by problems with detecting collisions.
> >
> > But software doesn't detect collisions. It just records what
> > hardware said it did. It looks like you have a 10 Mb/s card
> > on a 100 Mb/s network. The collisions reported are how the
> > hardware throttles the difference in physical-link speed.
>
> The hub is a 10/100 one, and the 3 RTL8029 are 10 Mbps only.
>
> > It is possible that software didn't initialize a 100 Mb/s
> > device and instead initialized it to 10 Mb/s, but you
> > don't have any evidence of that presented.
>
> No, because RTL8029 are 10 mbps only (they are BNC/RJ45 NICs).
>
> But what I thought was that maybe, they were initialised as full duplex,
> not half duplex. But again, I don't know where I can check that. I added
> some printks and determined that the code used to init them full duplex
> was never used. And there's no way to force them half duplex with this
> driver.

There is a DOS utility which configure duplex settings for RTL8029.

Also check /proc/interrupts and /proc/ioports for IRQ/ioport collisions.
--
vda


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: ne2k-pci uncorrectly detecting collisions ?
  2004-05-05 19:45     ` Denis Vlasenko
@ 2004-05-06  9:52       ` Lucas Nussbaum
  0 siblings, 0 replies; 6+ messages in thread
From: Lucas Nussbaum @ 2004-05-06  9:52 UTC (permalink / raw)
  To: Denis Vlasenko; +Cc: linux-kernel

On Wed, May 05, 2004 at 10:45:39PM +0300, Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua> wrote:
> > But what I thought was that maybe, they were initialised as full duplex,
> > not half duplex. But again, I don't know where I can check that. I added
> > some printks and determined that the code used to init them full duplex
> > was never used. And there's no way to force them half duplex with this
> > driver.
> 
> There is a DOS utility which configure duplex settings for RTL8029.
 
Thanks a lot, that did the trick.
-- 
| Lucas Nussbaum
| lucas@lucas-nussbaum.net    lnu@gnu.org    GPG: 1024D/023B3F4F |
| jabber: lucas@linux.ensimag.fr   http://www.lucas-nussbaum.net |
| fingerprint: 075D 010B 80C3 AC68 BD4F B328 DA19 6237 023B 3F4F |

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2004-05-06  9:52 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-05-05 12:35 ne2k-pci uncorrectly detecting collisions ? Lucas Nussbaum
2004-05-04 12:55 ` backblue
2004-05-05 13:00 ` Richard B. Johnson
2004-05-05 13:10   ` Lucas Nussbaum
2004-05-05 19:45     ` Denis Vlasenko
2004-05-06  9:52       ` Lucas Nussbaum

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox