[vortex-bug] Re: Asymetric throughput with 3c905b NIC (workaround)

[Regis Duchesne]

Andrew,

First, thanks for replying.

> This is pretty amazing stuff.
Yep. I'm puzzled.

> A few things to try:
> 
> echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
> 
> This makes the machine not reply to pings.  Then you can isolate the
> traffic directions.
> 
> time ping -s 100 -c 1 -l 10000
> 
> to send 10,000 100 byte packets.
> 
> This is a pure unidirectional speed test.  (Maybe ttcp can do that with
> UDP?)
Yes, ttcp can do that (-u option).

Here are the results:

Machine A has a vanilla kernel 2.2.12
Machine B has a RedHat kernel 2.2.12-20

ttcp
----
 A -> B OK  (93 Mb/s)
 A <- B Bad (40 Mb/s)

This confirms my previous test

ping
----
 A -> B OK (10 s.)
 A <- B OK (10 s.)

So it seems that unidirectional works fine. This is when there is
two-way traffic that the problem occurs.

ttcp -u
-------
 A -> B OK (95 Mb/s)
 A <- B OK (95 Mb/s)

This confirms the result obtained by the ping method.

> Try netperf (www.netperf.org).  Not sure that this will provide a
> solution, but it's a second opinion.
I'm going to try it.

> With 2.4, don't do any performance testing without setting SLAB_DEBUG to
> 0 in mm/slab.c - SLAB_DEBUG reduces TCP throughput by 40%.  But this
> isn't an explanation.
Ok I haven't checked that. That's why I have been using only 2.2.12
kernels in today's tests.

> Use vortex-diag -a to verify that you're running full-duplex.
On machine A: ./vortex-diag -a

vortex-diag.c:v2.01 5/17/2000 Donald Becker (becker@scyld.com)
 http://www.scyld.com/diag/index.html
Index #1: Found a 3c905B Cyclone 100baseTx adapter at 0xe800.
The Vortex chip may be active, so FIFO registers will not be read.
To see all register values use the '-f' flag.
Initial window 7, registers values by window:
  Window 0: 0000 0000 0000 0000 f5f5 00bf 0000 0000.
  Window 1: FIFO FIFO 0000 0000 0000 0000 0000 2000.
  Window 2: 1000 674b 1681 0000 0000 0000 000a 4000.
  Window 3: 0000 0180 05ea 0020 000a 0800 0800 6000.
  Window 4: 0000 0000 0000 0cd2 0003 8880 3400 8000.
  Window 5: 1ffc 0000 0000 0600 0807 06de 06c6 a000.
  Window 6: 0000 0000 0000 0000 1000 0000 0000 c000.
  Window 7: 0000 0000 0000 0000 0000 0000 0000 e000.
Vortex chip registers at 0xe800
  0xE810: **FIFO** 00000000 0000002d *STATUS*
  0xE820: 00000020 00000000 00080000 00000004
  0xE830: 00000000 e3e51c1b 07c4f0d0 00080004
 Indication enable is 06c6, interrupt enable is 06de.
 No interrupt sources are pending.
 Transceiver/media interfaces available:  100baseTx 10baseT.
Transceiver type in use:  Autonegotiate.
 MAC settings: full-duplex.
 Station address set to 00:10:4b:67:81:16.
 Configuration options 4000.

On machine B: ./vortex-diag -a

vortex-diag.c:v2.01 5/17/2000 Donald Becker (becker@scyld.com)
 http://www.scyld.com/diag/index.html
Index #1: Found a 3c905B Cyclone 100baseTx adapter at 0xfc00.
The Vortex chip may be active, so FIFO registers will not be read.
To see all register values use the '-f' flag.
Initial window 7, registers values by window:
  Window 0: 0000 0000 0000 0000 f5f5 00bf 0000 0000.
  Window 1: FIFO FIFO 0000 0000 0000 0000 0000 2000.
  Window 2: 1000 984b f1eb 0000 0000 0000 000a 4000.
  Window 3: 0000 0180 05ea 0000 000a 0800 0800 6000.
  Window 4: 0000 0000 0000 0cd2 0003 8880 0000 8000.
  Window 5: 1ffc 0000 0000 0600 0807 06de 06c6 a000.
  Window 6: 0000 0200 0000 8001 0100 13ac 0cc7 c000.
  Window 7: 0000 0000 0000 0000 0000 0000 0000 e000.
Vortex chip registers at 0xfc00
  0xFC10: **FIFO** 00000000 0000000a *STATUS*
  0xFC20: 00000020 00000000 00080000 00000004
  0xFC30: 00000000 b25b4da5 0b7b89d0 00080004
 Indication enable is 06c6, interrupt enable is 06de.
 No interrupt sources are pending.
 Transceiver/media interfaces available:  100baseTx 10baseT.
Transceiver type in use:  Autonegotiate.
 MAC settings: half-duplex.
 Station address set to 00:10:4b:98:eb:f1.
 Configuration options 4000.

OK, it seems that this one if half-duplex only. It is strange because
autonegotiate is on, and the NIC knows the other NIC very well :)

I have just re-loaded the module with the full_duplex=1 option, and it
works just fine in both directions in bi-directional mode now (at
least for those two kernels. I'm going to try with 2.4.0-test1 on both
sides)

So I have a workaround, but the initial problem remains: why is there
a mis-agreement in the negotiation as far as duplex mode is concerned?
Is this a driver bug? When do card negotiate the duplex mode? At
module load time, or each time you plug a new cable into the NIC?

Thanks a lot,
-- 
hpreg