Stress Testing a Gigabit LAN

[Coleman Blake_2]

I am trying to determine the maximum throughput that out gigabit LAN will support and have run into one potential problem and would like advice on two other issues. The problem is that both PerfView (PV) and Performance Manager (OVPM) seem to under report the transfer rate by a factor of four. The two issues are using ttcp as a transfer mechanism and the way I am generating traffic to test the LAN.

If I transfer a large file (30GB) and divide the size by the duration of the transfer, I get a transfer rate of about 20 MB/s which is consistent with the I/O rate of the disks. If I check the transfer rate with PV and OVPM, the maximum rate is 5 MB/s. Has anyone else noticed this or am I doing something wrong?

Since I want to test at rates higher than the single disk I/O, I am using ttcp to get data from standard input on the source system and "sink" it on the target system. Ttcp seems to be working fine. Is there a better tool?

In order to generate traffic to pipe into ttcp, I "cat" a 300KB text file in an infinite while loop. It's the text part of a kernel patch so it's probably random enough. When I do this, the "cat" process eats up about 75% of one CPU and the system load average is at or below 1. Checking with PV and OVPM, I see no bottlenecks and very little disk activity, verifying that the file is being read from cache and not the disk. Is there a better way to generate traffic for a test like this?

Thanks,

Coleman Blake
Peace Corps

[Steven E. Protter]

Coleman,

I'm not sure you are doing anything wrong.

There are a number of factors that come to play in this kind of performance data collection.

1) The Interface card speed.
2) Other things going on on the system, particularly disk i/o issues.
3) Speed of the backbone your LAN card is connected to.
4) Configuration and number of routers between you and your destination.
5) Speed of any other hardwaer between you and your destination.

Just take that into consideration.

I've attached some scripts that might be helpful to you.

SEP

[rick jones · Accepted solution]

if I had to hazard a guess, it would be that those two tools are sampling the byte counters infrequently enough that they are wrapping. the things are still (not sure about 11.23) a measly 32-bit.

i'd take netstat -p tcp and lanadmin -g mibstats snapshots just before and just after something like a 60 second netperf TCP_STREAM test:

$ netstat -p tcp > /tmp/before
$ lanadmin -g mibstats >> /tmp/before
$ netperf -v 2 ... -l 60 ...
$ netstat -p tcp > /tmp/after
$ lanadmin -g mibstats >> /tmp/after
$ beforeafter /tmp/before /tmp/after > /tmp/delta

and then make sure that the byte deltas are consistent with what netperf reports.

You can get beforeafter from:

ftp://ftp.cup.hp.com/dist/networking/tools/

and you can get netperf via:

http://www.netperf.org/

With netperf you can also undertake latency measurements - since networks live not on bandwidth alone :)

[Coleman Blake_2]

NETPERF was the answer. I'm getting 400+ bps. The buffers in the other performance tools, PV and OVPM, were rolling over.

[rick jones]

400+ mbit/s may be good, might not be - what sort of systems are on either side, and did you experiment with the socket buffer sizes (-s and -S)?

[Coleman Blake_2]

Not yet, but I will now that I have the tools.

Thanks for the pointers.

Coleman.