Snatched from original location by deice.
Original by Wayne E Goodrich (Outlaw)
Introduction
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).
Original by Wayne E Goodrich (Outlaw)
Introduction
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).
Netcat
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.
listening on [any] 2222 ...
On machine A, notice:
connect to [192.168.0.8] from (UNKNOWN) [192.168.0.4] 34111
Stop after 10 seconds by typing ctl-c and jot down the time taken:
sent 87478272, rcvd 0
real 0m9.993s
user 0m2.075s
sys 0m0.939s
On machine A, note the data sent (in bytes)
sent 0, rcvd 87478392
Now multiply the bytes rcvd by 8 to get total bits, then divide by the time: Result is 70Mb/s
Next up - Gb ethernet segment
Machine A
Machine B
Machine A
connect to [192.168.1.5] from cfms6-p [192.168.1.6] 33855
sent 0, rcvd 1155325952
Result is .9Gb/s
Lastly - a 10Mb ethernet segment
listening on [any] 80
sent 0, rcvd 8437760
Result is 6.7Mb/s
Conclusion
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.
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.
- which nc /usr/bin/nc
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:
- nc -v -v -l -n -p 2222 >/dev/null listening on [any] 2222 ...
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:
connect to [192.168.0.8] from (UNKNOWN) [192.168.0.4] 34111
Stop after 10 seconds by typing ctl-c and jot down the time taken:
sent 87478272, rcvd 0
real 0m9.993s
user 0m2.075s
sys 0m0.939s
On machine A, note the data sent (in bytes)
sent 0, rcvd 87478392
Now multiply the bytes rcvd by 8 to get total bits, then divide by the time: Result is 70Mb/s
Next up - Gb ethernet segment
Machine A
- nc -v -v -l -p 2222 >/dev/null
Machine B
- yes | nc cfms5-p 2222 >/dev/null punt!
Machine A
connect to [192.168.1.5] from cfms6-p [192.168.1.6] 33855
sent 0, rcvd 1155325952
Result is .9Gb/s
Lastly - a 10Mb ethernet segment
- nc -v -v -l -p 80 > /dev/null
listening on [any] 80
sent 0, rcvd 8437760
Result is 6.7Mb/s
Conclusion
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.
RSS Feed