By Wayne E Goodrich (Outlaw)
(Transferred from the wiki by Peter)
Sometimes it is necessary to test your network interfaces for throughput, however, before you start by using your favorite file transfer utility for measuring the throughput, consider what you are actually measuring. To illustrate this, consider a Database Administrator who has been at whit's end trying to configure a clustered database among a few nodes with Gb ethernet adapters. Things are not working and he naturally suspects the hardware to be at fault. So he calls you over to show you that when using secure ftp to move a file between nodes, the transfer rate is not consistent with Gb ethernet by a long shot. He thinks he measured network throughput, but he probably measured the write throughput of the remote system's disks. What is needed, then, is to remove the limiting factor, which happens to be the disks (and perhaps the encryption overhead of sftp).
To eliminate the disks from having any part of the transfer, we will use netcat. Netcat is described as being a "feature-rich network debugging and exploration tool". It can be obtained from Source Forge, or it may already be available in your distribution.
To set up our test, we'll use two machines, one to listen for a connection, and one to connect and send the data stream. In each test we'll use a ten second session and we'll test on three different LANs that differ in speed. The output file will be /dev/null in order to remove the disk from the equation.
Let's Begin on a 100Mb network segment
On machine A (192.168.0.8, start netcat as an ordinary user thusly:
On machine B, send data to machine A, using the yes command over port 2222, using netcat - timing the session.
nc -v -v -l -n -p 2222 >/dev/null
listening on [any] 2222 ...
On machine A, notice:
time yes|nc -v -v -n 192.168.0.8 2222 >/dev/null
(UNKNOWN) [192.168.0.8] 2222 (?) open
Stop after 10 seconds by typing ctl-c and jot down the time taken:
connect to [192.168.0.8] from (UNKNOWN) [192.168.0.4] 34111
On machine A, note the data sent (in bytes)
sent 87478272, rcvd 0 real 0m9.993s
Now multiply the bytes rcvd by 8 to get total bits, then divide by the time: Result is 70Mb/s
sent 0, rcvd 87478392
Next up - Gb ethernet segment
nc -v -v -l -p 2222 >/dev/null
listening on [any] 2222 ...
yes|nc cfms5-p 2222 >/dev/null
Result is .9Gb/s
connect to [192.168.1.5] from cfms6-p [192.168.1.6] 33855
sent 0, rcvd 1155325952
Lastly - a 10Mb ethernet segment
Result is 6.7Mb/s
nc -v -v -l -p 80 > /dev/null
listening on [any] 80 ...
sent 0, rcvd 8437760
We have seen a handy way to use netcat for testing ethernet throughput. At least we can show that the throughputs are somewhat consistent with their respective LAN segment speeds. How can we account for not reaching the total advertised throughput? Perhaps the efficiency of the network drivers on the hosts or even that, in combination with processor overhead. I'd be interested in your comments, corrections or spam.