Paul Court

Network Speed Testing

Tools like are great for testing your general internet speed.

However, if you get slower than expected results they are not usually very informative as to where the slow down is. It could be your local network or WiFi, your internet connection or even the server at the destination end could be overloaded. They are also virtually useless for testing other sections of network which will normally run at speeds much greater than your actual broadband connection.

As part of a future project, I wanted to gather some accurate performance data for my current local network and internet connection, so it seemed like a good time to write up some info on the tools and techniques used to gather the data.

I am interested in testing Latency, Packet Loss and Throughput.

Latency is the measure of how long it takes an individual packet of data to leave the source machine, traverse the network connection and arrive at the destination machine. Normally this is measured in milliseconds (ms) for the entire round trip from source machine to destination and back again.

Packet Loss are the number of packets which leave the source machine, but never arrive at the destination (or the acknowledgement message doesn't make it back to the source), which will cause that packet to have to be re-sent.

As I enjoy playing online games quite a bit, I am interested in making sure my network connections are keeping latency and packet loss as low as possible.

Throughput is how much data that you can transfer in any given time frame. Normally this is measured in Kilo, Mega or Giga bits per second. Most broadband connections in the UK, are asymmetrical which means they operate at different speeds when receiving data (downloading) than sending (uploading).

Faster is normally better. Higher throughput means you can do more with your network as the same time or download/upload large items more quickly.

Measuring Latency and Packet Loss

The main tool I'm using to measure latency and packet loss is ping. You simply give it the name/IP of the server you want to test against...

$ ping

...and it sends repeated ICMP packets and records the round trip time and the number of packets that go AWOL. On Linux, the command will run indefinitely until you press CTRL-C, then it will output a summary of the run.


$ ping
PING ( 56(84) bytes of data.
64 bytes from ( icmp_seq=1 ttl=237 time=27.8 ms
64 bytes from ( icmp_seq=2 ttl=237 time=30.2 ms
64 bytes from ( icmp_seq=3 ttl=237 time=41.6 ms
64 bytes from ( icmp_seq=4 ttl=237 time=29.9 ms
64 bytes from ( icmp_seq=5 ttl=237 time=28.5 ms
--- ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 27.834/31.644/41.657/5.086 ms

From these results, we can see that 5 "pings" were sent and the average the latency from my home to my webserver (hosted on AWS) is 30ms, and no packets were dropped.

The longer you leave ping running, the more data you collect for calculating the results. This can be useful for gathering information on the stability of a network link.

Comparing Ethernet vs WiFi

Lets use ping to gather some data on the differences between a wired Ethernet connection and a WiFi connection, I'm going to ping my NAS box 100 times from my PC which is on a wired gigabit network and then repeat the process from my laptop which is on WiFi.

First, the wired results:

$ ping
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=64 time=0.248 ms
64 bytes from icmp_seq=104 ttl=64 time=0.254 ms
--- ping statistics ---
104 packets transmitted, 104 received, 0% packet loss, time 105448ms
rtt min/avg/max/mdev = 0.229/0.257/0.368/0.022 ms

As you can see from the summary, this link is stable - no packet loss and no major differences between min, max and average. Now for the WiFi:

$ ping
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=64 time=1.488 ms
64 bytes from icmp_seq=104 ttl=64 time=4.659 ms
--- ping statistics ---
105 packets transmitted, 105 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.057/2.035/4.659/0.517 ms

Again this link is fairly stable - Not massive differences in min, max and average. I have direct line if sight to the WiFi router, so I was expecting this. However, look at what happens if I re-run the WiFi test from another room:-

PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=64 time=25.938 ms
64 bytes from icmp_seq=1 ttl=64 time=18.372 ms
64 bytes from icmp_seq=2 ttl=64 time=10.398 ms
Request timeout for icmp_seq 3
64 bytes from icmp_seq=4 ttl=64 time=45.883 ms
Request timeout for icmp_seq 5
64 bytes from icmp_seq=6 ttl=64 time=48.882 ms
64 bytes from icmp_seq=7 ttl=64 time=75.051 ms
64 bytes from icmp_seq=8 ttl=64 time=9.289 ms
64 bytes from icmp_seq=9 ttl=64 time=28.852 ms
64 bytes from icmp_seq=10 ttl=64 time=42.006 ms
64 bytes from icmp_seq=11 ttl=64 time=18.104 ms
64 bytes from icmp_seq=12 ttl=64 time=9.132 ms
64 bytes from icmp_seq=13 ttl=64 time=7.767 ms
64 bytes from icmp_seq=14 ttl=64 time=4.844 ms
64 bytes from icmp_seq=15 ttl=64 time=47.115 ms
Request timeout for icmp_seq 16
64 bytes from icmp_seq=17 ttl=64 time=12.904 ms
64 bytes from icmp_seq=18 ttl=64 time=1.305 ms
64 bytes from icmp_seq=84 ttl=64 time=1.700 ms
64 bytes from icmp_seq=85 ttl=64 time=48.140 ms
64 bytes from icmp_seq=86 ttl=64 time=72.957 ms
64 bytes from icmp_seq=87 ttl=64 time=95.019 ms
64 bytes from icmp_seq=88 ttl=64 time=2.340 ms
64 bytes from icmp_seq=104 ttl=64 time=3.290 ms
--- ping statistics ---
105 packets transmitted, 102 packets received, 2.9% packet loss
round-trip min/avg/max/stddev = 1.155/8.313/95.019/16.525 ms

I've included quite a few more lines of the output so you can see what was happening. Although we still have reasonable figures for min and average, you can see that max jumps up to almost 100ms and we have 3% packet loss! This is actually pretty typical for an average WiFi link and could be caused by a number of factors, interference on the radio frequency, the laptop and base station deciding to switch channels, etc.

For browsing the web and tweeting rubbish, 3% packet loss is not an issue - even for accessing files on the local network, it's still not an issue as the error correction will normally kick in and resend the missing packets without you even noticing.

However, if you were playing an online game such as a first person shooter you now have a 3% chance that a crucial headshot you make at your end of the game won't actually reach the server and your opponent won't die! :-(

It's also important to note that OSX was still reporting "4 bars" of signal strength. This wasn't even a weak signal.

I wanted to try and capture data from a "weak" signal, but it seems OSX now likes to only show me 4 bars or disconnect completely from the network. So I had to go out into the garden and find the point at which the connection was re-established and test from there. Again, OSX was telling me this was a "full" signal:-

--- ping statistics ---
83 packets transmitted, 47 packets received, 43.4% packet loss
round-trip min/avg/max/stddev = 4.819/2408.444/11302.063/3052.634 ms

You would definitely start to notice this even with just "casual browsing".

Measuring Throughput

Now that we know how to test how stable a connection is, we can move on to measuring throughput - how much we can send or receive over the link.

To measure this I am going to use a tool called iperf. This useful little tool has two main modes of operation - client and server. You start a server on a machine on one side of the link you want to test and run the client from the other side.

Starting the server is done simply as follows:-

$ iperf -s
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)

The command will now sit and wait for incoming client connections on port 5001.

In another terminal I can then run in client mode to perform a speed test:-

$ iperf -c localhost
Client connecting to localhost, TCP port 5001
TCP window size: 2.50 MByte (default)
[  3] local port 45558 connected with port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  67.8 GBytes  58.2 Gbits/sec

58.2 Gbits/sec!! Now that would be an awesome internet connection!

As I have run the test on the same machine using localhost, there isn't actually a physical network link involved so what we have here is the maximum speed of part of the network stack within my desktop machine - no packets actually left and travelled anywhere.

Lets try something a bit more useful.

This time, I am going to test the speed between my desktop machine and my NAS box which lives on the other side of the network. So I am testing the Ethernet link which runs from my computer to the switch and then from the switch to the NAS box. All devices should be supporting and using gigabit speed.

First, I ssh into the NAS box and start iperf in server mode as described above:-

root@NASBOX2:~# iperf -s
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)

And then run the client from my desktop:-

iperf -c
Client connecting to, TCP port 5001
TCP window size: 85.0 KByte (default)
[  3] local port 58330 connected with port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.10 GBytes   943 Mbits/sec

We can see from the results that the test ran for 10 seconds (the default time), it transferred 1.10 GBytes of data and has a bandwidth of 943 Mbits/sec. This is just about perfect for a Gigabit network link and confirms that both devices are running at full speed with no bottlenecks in the network link.

It's also worth noting that the things we want to transfer: text, pictures; videos; music, etc. is all measured in Bytes and the bandwidth of a link is measured in Bits. There are 8 bits to a byte, so a rough estimate of what you should be able to transfer and how long it would take would be to multiply the size of the data you want to send by 8, and then divide it by your connection speed.

So to send a 10 GB (Gigabyte) file to my NAS box, that would be:-

  • 10GB * 8 = 80 Gb (Gigabits - note the lowercase "b")
  • 80Gb / .920 Gbps = 86.95 seconds. (Note, I converted 943Mbps into Gbps by dividing it by 1024)

Useful Options

Two of the iperf options I find most useful are "-t" and "-i".

"-t" lets you specify how long you want the test to run for (the default is 10 seconds), and "-i" lets you specify at what interval you want the stats to be reported. If you specify "-t 0" the test will run continuously until you press CTRL-C.

Lets see what happens when I run the test this way from my laptop as I walk from the office to the kitchen to gather some throughput data on my WiFi network:-

$ iperf -i 2 -t 0 -c
Client connecting to, TCP port 5001
TCP window size:  129 KByte (default)
[  4] local port 54604 connected with port 5001
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0- 2.0 sec  42.5 MBytes   178 Mbits/sec
[  4]  2.0- 4.0 sec  36.6 MBytes   154 Mbits/sec
[  4]  4.0- 6.0 sec  39.9 MBytes   167 Mbits/sec
[  4]  6.0- 8.0 sec  41.1 MBytes   172 Mbits/sec
[  4]  8.0-10.0 sec  44.2 MBytes   186 Mbits/sec
[  4] 10.0-12.0 sec  9.62 MBytes  40.4 Mbits/sec
[  4] 12.0-14.0 sec  13.6 MBytes  57.1 Mbits/sec
[  4] 14.0-16.0 sec  24.6 MBytes   103 Mbits/sec
[  4] 16.0-18.0 sec  19.0 MBytes  79.7 Mbits/sec
[  4] 18.0-20.0 sec  10.1 MBytes  42.5 Mbits/sec
[  4] 20.0-22.0 sec  2.00 MBytes  8.39 Mbits/sec
[  4] 22.0-24.0 sec  0.00 Bytes  0.00 bits/sec
[  4] 24.0-26.0 sec  0.00 Bytes  0.00 bits/sec
[  4] 26.0-28.0 sec  0.00 Bytes  0.00 bits/sec
[  4] 28.0-30.0 sec  12.6 MBytes  53.0 Mbits/sec
[  4] 30.0-32.0 sec  48.9 MBytes   205 Mbits/sec
[  4] 32.0-34.0 sec  50.6 MBytes   212 Mbits/sec
[  4] 34.0-36.0 sec  45.8 MBytes   192 Mbits/sec
[  4] 36.0-38.0 sec  49.2 MBytes   207 Mbits/sec

What we can see here is that as soon as I move away from my strongest signal spot, the speed varies by quite a large margin until I eventually get out of reach of the office base station and hand over to the kitchen one (the 6 seconds in the middle where no data was transferred).


By running tests with iperf and ping, it is easy to visualise characteristics of specific network links which can help with finding faults and congestion or just to see if you could stream 4K video to your TV over the WiFi.

Both tools have a multitude of options which could help tune the tests to specific requirements, so it is worth taking a little time to read the docs and figure out what would work best for you if you are going to perform your own tests. I have only covered the basics, as these will suffice for the tests I want to do.

I'll be making use of these tools for testing a long range WiFi link which I will hopefully be publishing the results of here very soon.

There are no comments available on this blog, but please do send me your thoughts and feedback via twitter by replying to this tweet.