There are so many network speedtests available: Ookla, Fast.com, NDT, iperf, … which one should you use? In this article, I’ll go over this. Also, I presented this topic at the Wireless LAN Professionals conference in February 2018. You can find the video here.
If you have a few years’ experience in network troubleshooting, you know that when you receive a ticket from a user complaining about “slowness”, in most cases, it’s the user’s device or the application. But you are still tasked with proving that, “It’s Not the Network.”
There are many ways to do this, but the ‘quick and dirty’ way to measure internet speed is to run a speedtest – such as the one provided by Ookla. There are a dozen similar tests (with every major TelCo provider having their own speed test) and a number of free and paid mobile device apps available. In this post, we’ll cover five of them, their different features and how they can be used in different scenarios.
It’s pretty straightforward how all of these speed tests work: a device uploads and downloads a large file to a server, and based on how long it takes, it calculates the connection bandwidth. In addition, it can measure some other metrics as well such as latency and jitter.
1. Ookla
This is the most well known and most commonly used speed test. You can ask the user that complained to go to speedtest.net, click the “Go” button and tell you what they see on their browser.
If these numbers are high enough (high enough being dependent on the user’s requirements) then you can at least know that the bandwidth between the user’s device and the Internet (where the Ookla server is) is not an issue.
Since this test uses an Internet-based server the test path is the following:
The path includes the home wireless and wired LAN, the internet server provider network, the and Internet portion between the ISP and the ookla server. Consequently, if the measured bandwidth is low, we don’t know what part of the connection is responsible. In addition, if the public server is running more than one speed tests then it might not be able to give accurate and consistent measurements. There are around 7,000 public Ookla servers listed here.
2. Google NDT
If you google “speedtest” you will find the following prompt:
Google has partnered with the Measurement Lab (M-Lab) and promotes their speed test, NDT. This is similar to Ookla, in the sense that you can use public servers maintained by third parties for testing. There are around 150 public NDT servers, however, NDT is an open-source project; this opens the option to install a test server in your own network and enables you to isolate parts of it as follows:
By having full control of the server the measurements are more accurate and consistent, and you are able to verify if bandwidth issues are caused by internal networking issues or not. In addition, NDT has a command line test utility that you can use to script or automate this measurement.
3. Netflix Fast.com
Netflix maintains their own speed test at fast.com, in order to give their users ISP-independent testing that also use Netflix servers. The difference with Ookla is that it uses Netflix servers primarily to report download speeds of an internet connection. Obviously, streaming customers are more interested in their download rather than their upload bandwidth, and Netflix provides a simple and ad-free test for that. I like Fast because of its simplicity: as soon as fast.com loads, the test starts running and immediately provides value. There is no button to click. It can’t be dumber than that. If you click on the additional options, you can also review the upload performance and do a bufferbloat test.
4. Open Source HTML
This is another open source HTML based test that you can find here. There are no public servers for this test, so if you want to use it, you’d have to set up your own server and install the software.
It gives more or less the same information as Ookla and NDT, with the addition of jitter which can be useful when debugging VoIP issues.
5. iPerf
iPerf is a utility that can be used on the command line or on a GUI to test bandwidth. It’s not browser-based, and it requires to download or install software on the host and the server used for the testing. In that regard, it’s a bit more involved to use, but it gives far more flexibility and options. For example, you can test TCP and UDP traffic, and specify parameters such as the TCP window size, the type-of-service (TOS) for outgoing packets, the TCP maximum segment size, and others. There are a few public iPerf servers but are not well maintained and reliable. For more details on how to use iPerf you can read this post.
The command line output of iPerf looks like this:
Speed Tests Comparison Table
In the following table, I have sorted all these tests with respect to how easy they are to use, with fast.com being the easiest, and iPerf the least easy. The benefit of using iPerf is that you have the ability to customize many parameters that are not possible to customize with the HTML-based tests.
| Option | Complexity | Custom | Private Server | Scripting Available | Num. of Public Servers | Notes |
|---|---|---|---|---|---|---|
| NetFlix Fast | low | 1 | No | No | ? | Download, Upload, Latency |
| Ookla | low | 1 | No | Yes | 16,000+ | Dowbload, Upload, Latency |
| NDT | average | 2 | Yes | Yes | Approx. 150 | Download, Upload, Latency |
| HTML Speedtest | average | 2 | Yes | Yes | n/a | Download, Upload, Latency, Jitter |
| iPerf | high | 4 | Yes | Yes | 5-10 | TCP/UDP throughput, Jitter, Packet loss |
Speedtest Consistency
Try to run all of the previous five tests on the same hosts and on the same network. You will notice significant discrepancies in the bandwidth measurements they provide. In addition, if you try the same test on two different browsers you might also see discrepancies in the measurements. This is because each speed test implementation might handle data and timing differently. For example, some tests discard the first few seconds worth of measurements. They do this because those values tend to be lower than the average. In fact, both the server and the device ramp up the upload and download process. According to my experience, the most reliable and accurate test is iPerf.
If you were to ask, “Then…which test should I use?” I would answer: “Pick one and be consistent”. The important observation with these tests is to look for changes in the measurements. Save past/historical measurements.It will help you create a baseline that you can use to detect if there‘ are any issues that might affect your users‘s a sudden drop in throughput.
NetBeez Speed Tests
At NetBeez, we use network monitoring agents to detect issues that affect the end user. NetBeez works by installing agents on both wireless and wired networks that run periodic tests to measure latency, HTTP response time, bandwidth and more. On the NetBeez dashboard, you can automate the execution of bandwidth testing with iPerf and network speed to run on a specific schedule and collect the historical information to build statistics, baselines, and get alerted when something goes wrong.
In addition with NetBeez, you can collect measurements on dozens or hundreds of agents. This allows you to capture user experience data from all your remote sites. It also enables your IT be proactive with any issues that may come up. You can detect and troubleshoot WiFi and wired issues proactively even before they affect your end user. Just request a demo to test it!
