Are You Being Misled by Network Speed Tests? The Reality Might Surprise You!

The media is filled with hyperbolic claims that "Our network is the fastest!"

And there are many so-called "Speed Test" tools available on the Internet. Most are easily run in a web browser. Should you trust those tools?

Not really.

The popular speed testing tools provide a very narrow and limited measure of network "speed".

It is quite possible that a network that is rated as "fast" could actually deliver poor results to many applications. Why is this so?

Breaking Down the Unreliability of Speed Tests

Internet speed tests 

are a traditional tool used by individuals and organizations alike to gauge the performance of their internet connections. However, these tests can often provide unreliable and inconsistent results due to various factors. Here, we delve deeper into the components of these tests and why they might only sometimes be the best indicators of your actual internet speed.

Limited Test Parameters

Most internet speed tests rely on limited parameters, such as ICMP Echo/Reply ("ping"), to measure the round-trip time. However, these tests often do not accurately indicate whether they are reporting the actual round-trip time or halving it to estimate one-way latency. This lack of clarity can result in misleading data, as the latency experienced during regular internet use might differ.

TCP Bandwidth Measurement

The HTTP GET (for downloading) and PUT (for uploading) methods are commonly used to measure TCP bandwidth. However, these methods only provide a snapshot of the network's performance at a specific moment. They might not accurately represent its overall bandwidth capacity. Moreover, these methods are influenced by various factors, such as network congestion and server load, which can further skew the results.

Inconsistent Use of Protocols

Different speed test tools employ various protocols, including IPv4 and IPv6, or they might use the protocol chosen by the underlying web browser and IP stack. This inconsistency can lead to varying results, as different protocols might have other performance characteristics. Moreover, the protocol choice can influence the route the data packets take, potentially affecting the test results.

Additional Tools and Their Limitations

Some more advanced speed test tools incorporate additional features like Traceroute and DNS queries to provide a more comprehensive view of the network's performance. However, these tools have their own set of limitations:

• Traceroute: While it can be a helpful tool for identifying the paths that data packets take, it can sometimes be improperly implemented using ICMP Echo packets instead of the more accurate UDP packets. This can result in less reliable data.

• DNS Queries measure the time it takes to convert a domain name into an IP address. However, this time can vary greatly depending on the DNS server's performance, which might not be a true reflection of the network's speed.

External Factors

Apart from the limitations of the tools themselves, external factors such as network congestion, time of day, and the physical distance between the user and the server can all influence the speed test results, making them less reliable as a consistent measure of network performance.

Some speed test tools use IPv4, some use IPv6, some use whatever the underlying web browser and IP stack chooses.

Sounds Good, So What's Wrong With 'Em?

Network performance is highly related to the way that the devices on a network converse with one another.

For example:

• Does the application software (and its server) use UDP or TCP?
  
  UDP is vulnerable to many network phenomena such as IP fragmentation, highly variable latency/jitter, packet loss, or alteration of the sequence of packets (i.e. the sender sends packets A, B, and C, the receiver gets them in the order B, C, A.), etc.
  
  TCP, on the other hand, although reliable, may withhold delivering data to the receiver while it internally tries to deal with packet losses, changes in end-to-end latency, and network congestion.
  

• Does the application's data have real-time constraints? For example, voice or video conferencing applications have very tight time constraints else the images may break up, freeze, or words be lost.
  

• How big are the chunks of data being sent? Larger data, particularly very large high-definition video, is more vulnerable to loss on the network, transient congestion problems, or IP fragmentation issues than are small data packets.

The bandwidth number generated by most speed test tools is based on World-Wide-Web HTTP GET (upload) and HTTP POST (download) transactions. These are bulk transfers of large amounts of data over TCP connections.

Bandwidth numbers based on TCP bulk transfers tend to be good indicators of how long it may take to download a large web page. But those numbers can be weak indicators of performance for more interactive applications (eg. Zoom).

Moreover, TCP tries to be a good citizen on the network by trying hard to avoid contributing to network congestion. TCP contains several algorithms that kick in when a new connection is started and when congestion is perceived. These algorithms cause the sending TCP stack to reduce its transmission rate and slowly creep back up to full speed. This means that each new TCP connection begins with a "slow start". In addition any lost packets or changes in perceived round-trip time may send the sending TCP stack into its congestion avoidance regime during which traffic flows will be reduced.

Modern web pages tend to be filled with large numbers of subsidiary references. Each of those tends to engender a Domain Name System lookup (UDP) and a fresh TCP connection (each with its own slow start penalty.) As a consequence, modern web page performance is often not so much limited by network bandwidth but more by protocol algorithms and network round-trip times.

What You Should Be Looking for when Testing Internet Speed

Unfortunately a full measure of the quality and speed of a network path includes a large number of often obtuse numbers.

• Whether the path contains parallel elements due to load balancing or bonding of physical links. (In other words, it is good to know whether all the traffic follows the same path or whether it is divided among multiple paths with possibly quite different characteristics.)

• Whether the network path is symmetrical or whether each direction takes a different route. (This is very common.)

• Path MTU (Maximum Transmission Unit for the entire one-way path - a separate value is needed for each direction.)

• End-to-end latency, and often more importantly, a statistical measure of the packet-to-packet variation of that delay, often called "jitter".

• Packet loss rates and a measure of whether that loss occurs continuously or in bursts. (This is particularly important on paths that include technologies subject to outside interference and noise such as wireless links.)

• Buffering along the path (in other words, whether the path may suffer from "bufferbloat".)

• Packet re-sequencing rates and a measure of whether that is burst behavior or continuous.

• Whether there are "hidden" proxy devices (most likely HTTP/HTTPS or SIP proxies) that are relaying the traffic.

• Whether there are any rate limiters or data quotas on the path.

What Can You Do for More Accurate Network Test Results?

While users have limited control over network protocols and applications, there are straightforward steps to take to obtain more accurate network test results. Here are some direct strategies:

Choose the Right Wi-Fi Band

If you are using Wi-Fi and Bluetooth simultaneously, connect to the 2.4GHz Wi-Fi band to prevent rapid switching between Bluetooth and the 5GHz Wi-Fi band, which can cause packet loss and jitter.

Update Your Router

Ensure your router has the latest anti-buffer bloat code to manage network traffic efficiently and reduce latency. Learn more about managing bufferbloat.

Monitor Network Usage

Be aware of the number of users and applications sharing your network resources. Try to schedule high-bandwidth activities during off-peak hours and use Quality of Service (QoS) settings on your router to prioritize essential applications.

Test at Different Times

Network speeds can fluctuate throughout the day. Conduct tests at different times to comprehensively view your network's performance.

Direct Connection to the Router

Connect your device directly to the router using an Ethernet cable for the most accurate speed test results. This eliminates potential interference and provides a clearer picture of your network's capabilities.

Close Unnecessary Applications

Before running a speed test, close any unnecessary applications on your device. These can consume bandwidth and skew the results of the test.

Update Network Drivers

Ensure that the network drivers on your device are up-to-date. Outdated drivers can slow down your connection and provide inaccurate test results.

By following these tips, you can achieve more accurate network test results and improve your internet experience.

What Tools Do Developers Have To Make Sure Applications Behave Well Under Real Life Conditions?

Enter the Network Emulator.

Speed test tools tend to give an optimistic report of how a network behaves for a highly constrained number of applications. Similarly, many network developers test their code only under optimal, laboratory conditions.

There are tools available to developers so that they can assure that their code and products are robust and behave well in the face of inevitable sub-optimal network conditions.

Most of these tools come under the heading of "network emulators". These effectively act as a bothersome man-in-the-middle, delaying some packets, tossing others, perhaps re-sequencing packets or even duplicating them.

Network Emulators come in a variety of capabilities and accuracies:

• Simple emulators are built into some mobile phones.

• There are a couple of open-source packages that typically exist as kernel modules for Linux or FreeBSD. These usually must be used through an arcane command-line interface. And their accuracy can vary wildly depending on the underlying hardware.

• There are external devices that are inserted into an Ethernet link (like one would insert an Ethernet switch.) These devices tend to have better accuracy and performance, and often have web-based graphical user interfaces. IWL's KMAX is in this category.

There are also mathematical emulators. Those are more for those who are designing large networks and want to perform queueing theory analysis of how that network might perform if new links are added or removed.