SUMMARY: OT: Network Speed Testing

From: Andrey Dmitriev <>
Date: Thu Sep 06 2007 - 14:07:03 EDT
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.

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 is a really good one, if you get two decent size x86 boxes with
enough horsepower to generate packets then this isa good option.

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

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

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.

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


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.

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> 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
Received on Thu Sep 6 14:07:17 2007

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:44:06 EST