[CLUE-Tech] Network DD

[David Anselmi]

"Timothy C. Klein" wrote:

[...]


> Ah, but I want dumb transfers.  I just want to measure how long a known set of
> data takes to transfer.  I don't want compression, tons of tcp overhead, etc.

But you don't necessarily want one data byte per TCP packet - then your TCP
overhead would outweigh your data.

[...]


> Gonna have to test some more.  These machines are separted by 25' of
> Cat5 wire that may not be up to 100Mb/s spec, so I am going to try it
> with a short piece of Cat 5e wire, just to rule out a lame line.

If you cable is a problem, you'll see error packets.  I'm not sure off hand what
the best way to count them is - ifconfig, maybe or somewhere in /proc.  You
could also try tcpdump or ethereal.  But if you aren't getting errors, your
cable is ok.

To avoid the problem of disk reads, you could send data from /dev/zero or some
other memory device (/proc/kmem, maybe?)

I went to a talk last week on the web 100 project - about maximizing TCP's
bandwidth usage.  TCP has several variables that affect its transmission rate
and it tries to adjust them to suit the connection it has.  Unfortunately its
behavior is to ramp up to saturation and then drop off and start over.  The
result is suboptimal, especially in fast networks (like 100Mb/s).

There was a slide that said a stock TCP stack could get about 30% of what a hand
tuned one got at 1Mb/s.  It gets worse at higher speeds.

The good news - the "new improved" TCP stack is available for the 2.4.16
kernel.  It includes better algorithms, better instrumentation for measuring
what's going on, and tools to use it all.

When the slides are available, they'll be here
http://www.fruug.org/mtgarchive/index.html or you can look for the web 100
project site.  It should have info on identifying what your throughput really is
and where the bottlenecks are (though the changes to the TCP stack are pretty
hard core).

Dave