SUMMARY: OT: Network Speed Testing

Thanks for tons of responses.

I am going to just list URLs and some comments I received.
Tools in no particular order. Ttcp and netperf were the most mentioned.

ttcp
http://www.netcordia.com/tnm/tnm31/ttcp.htm
Our quick and dirty test program is ttcp. It's been around forever, and
I'm sure that much better tools are available now, but it gives a quick
answer to TCP throughput.

"Ttcp times the transmission and reception of data between two systems
using the UDP or TCP protocols."  It attempts to remove non-network
limiting factors, such as disk I/O.

netperf
http://www.netperf.org/netperf/DownloadNetperf.html
netperf is a really good one, if you get two decent size x86 boxes with
enough horsepower to generate packets then this isa good option.

pathchar
.. find it limited in use these days as its pretty old.

netcps
it has a window$ executable nad the sources are available to compile.
I've never tried it in Solaris, only on Aix, but I think you shouldn't
have problems compiling it

netpipe
It reliably gives numbers that are near wirespeed on a LAN or across a
hub or switch.  I tend to believe it represents real world performance
rather well.

netcat
can be used to "pour" a large file through a socket, either TCP or UDP.
If your network is fast enough, disk I/O could be netcat's limiting
factor.

iperf
dast.nlanr.net

scp and ftp are good "practical" tests.  When you perform your tests you
need to know what's going on on your network, otherwise you could be
measuring the speed of your router or firewall under some typical or
non-typical load pattern.

hpn-ssh
I use ftp, as it seems to make best use of the bandwidth.  scp and ssh
(unless you have the High Performance modifications on both client and
server side) artificially limit the rate due to their network traffic
handling algorithms.  Nothing to do with encryption overhead per se, but
rather, statically defined flow control buffers.

ftp
ftp> put "|dd if=/dev/zero bs=8192 count=100000" /dev/null

General Comment from Garvey Wamboldt:
When you're testing TCP you want to know if the receiver has sent one or
more "backoff" messages.  Every time you get one your transfer speed is
cut in half.  TCP can be sensitive to buffer sizes which can trigger a
backoff.  Buffers need to be emptied, so the receiver is also sensitive
to load.  Large transfers in particular are sensitive to how much RAM
you have (when you don't have enough).  For long network segments (esp
satellite links) you need something like RFC1323, RFC3390 etc to ensure
you actually fill the pipe and keep data moving.
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers