Re: 2.1.99 TCP throughput problem

David S. Miller (davem@dm.cobaltmicro.com)
Fri, 1 May 1998 03:21:08 -0700


Date: Thu, 30 Apr 1998 20:50:03 -0700
From: Daniel Quinlan <quinlan@transmeta.com>

2.1.99 has an intermittent TCP throughput problem (which also
existed in pre-99-3, but not in 2.1.86) that only shows up when
sending data, but not when receiving data. This is on a single CPU
system running an SMP kernel, but it also happens on dual CPU SMP
systems and single CPU non-SMP systems. I'm using ttcp to test throughput.

Step 1) Try increasing the rx_copybreak value to 1512 in the Intel
eepro driver, I know you guys are Intel ether card fans over
at Transmeta ;-) prune_queue() behavior has changed and I
believe this may be the culprit.

As a side note, aren't your internal 100baseT nets at transmeta very
loaded most of the time? half-duplex is subsceptible to collisions,
and I don't know if the Intel cards do the 16-retry on collision
behavior or not... anyways...

This test is on a moderately loaded half-duplex 100BaseT network,
using ttcp in a while loop.

ttcp-t: 16777216 bytes in 1.81 real seconds = 70.75 Mbit/sec +++
ttcp-t: 16777216 bytes in 1.92 real seconds = 66.52 Mbit/sec +++
ttcp-t: 16777216 bytes in 46.14 real seconds = 2.77 Mbit/sec +++
ttcp-t: 16777216 bytes in 110.76 real seconds = 1.16 Mbit/sec +++
ttcp-t: 16777216 bytes in 51.67 real seconds = 2.48 Mbit/sec +++
ttcp-t: 16777216 bytes in 95.63 real seconds = 1.34 Mbit/sec +++
ttcp-t: 16777216 bytes in 1.73 real seconds = 74.04 Mbit/sec +++
ttcp-t: 16777216 bytes in 97.65 real seconds = 1.31 Mbit/sec +++
ttcp-t: 16777216 bytes in 57.92 real seconds = 2.21 Mbit/sec +++
ttcp-t: 16777216 bytes in 1.73 real seconds = 74.09 Mbit/sec +++
[...]

The speeds of each run are well grouped... perhaps the problem does or
doesn't happen completely on a per TCP connection basis.

Step 2) If #1 fails, send me strace and tcpdump wire output for ttcp
runs, one for a "good" run and one for a "bad" run. I need
straces from ttcp running at each end during such a run. It
is preferable to see tcpdumps from a "machine in the middle"
not one of the one's involved in the experiment.

Step 3) Given the results of #1 or #2, I fix it.

Later,
David S. Miller
davem@dm.cobaltmicro.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu