Using Speed Tests to Troubleshoot Wi-Fi? Understand What You SHOULD Be Getting

OK- we all know this routine… In the name of troubleshooting or diagnostics, you do some kind of network speed test as a data point. Sometimes, you use it as the ONLY data point to judge if the connection is good or bad. Maybe not the best practice, but let’s see if we can’t tighten up the process and expectations of speedtesting here.

This piece is written for those who may not realize the nuances of wireless networking versus wired when it comes to using simple speed tests as a diagnostic tool. Wi-Fi pros know that what’s being described here is actually one of the less-precise tools we have available, but it’s a handy one when more advanced WLAN tools are not on hand.

What SHOULD I be getting for throughput?

This question is of paramount importance. And the answer is a firm “that all depends”. If you are testing from a LAN or WLAN off to the likes of speedtest.net on the Internet, you really can’t know what the entire range of “good” is. You might be able to get as far as “well, it doesn’t suck, or it seems generally OK”, but you won’t be able to put a lot of precision on it. And, your results will be wildly variable (more on this in a minute). You absolutely have to consider the size of the ISP connection as well. Let’s say you are home and your internal network is healthy; your speedtest results should be very close to the rated connection speeds of your Internet connection (it can’t be faster). If you are on a robust business network that has multiple Gigabits of  ISP connectivity  to the Internet, the bottleneck to off-net speedtest.net will typically be out on the murky parts of the Internet or at the speedtest server itself.

There’s great luxury in setting up your own internal speedtest server (and lots of ways to do it, but that’s another blog article). You can get used to what you see from an internal server as a more reliable troubleshooting tool, but even here your results will vary whether you are on wired or Wi-Fi. Let’s explore all of this a bit.

Example 1- Wired Connection on Robust LAN

These are two consecutive runs to an off-network speedtest.net site from a verified Gig-connected PC on a business LAN, that minimally has a Gigabit path all the way to the Internet. All top-quality switches, routers, and cabling are in play on a professionally-built network. I ran these tests back to back. You’ll notice I was sent to two different servers on the Internet with greatly varying results.

That’s life on the Internet. And this test tells me little about the true quality of my internal network.

Using our internal, on-network speedtest server yields far more consistent results- generally within 10-20 Mbps with every pass for my wired Gig PC. All internet variability has been removed.

Now again- this is from a very stable, predictable WIRED gigabit connection.

Example 2- Wireless. A LOT More Complicated

So… you can probably accept the difference in what you should expect between on-network and off-network servers for doing speed tests, and can understand the variability of the Internet. And, I’m guessing that you’re OK with the fact that testing a Gig wired connection to an on-network speed test server should consistently give something close to a Gig. But on Wi-Fi, there are other important variables to consider when trying to use speed tests in troubleshooting.

Check out both of these, taken from my Nexus 7 tablet, on the same Wi-Fi network:

          

Clearly the first connection is better, right? There must be something wrong with the second one… yes? Especially if I told you that each test was run against the same model AP, with the same Gigabit uplink and all other variables equal. And it’s the same client device in each test. So the second connection is not as good. And the first connection is smoking- right?

The problem is that neither conclusion is true. And both are true. Maybe. Perhaps. How do you know?

As presented, you simply don’t have enough information to draw many conclusions- ESPECIALLY if you are troubleshooting and making determinations about network performance using speed tests. When it comes to wireless, you gotta think way past the simple elegance of Ethernet, Fast Ethernet, and Gigabit Ethernet that wired PCs enjoy, where all you have to consider is “am I getting close to 10, 100, or 1000 Mbps or my ISP speed?”.

To attempt to use throughput tests on Wi-Fi, and have them be even somewhat meaningful, you need to master the following.

1. Know your device. I used the Nexus 7 (2013 model) above. Looking up the specs shows me that it’s dual-band 11n, but doesn’t tell me the specific WLAN adapter in use. Looking a little deeper tells me my tablet DOES NOT USE MIMO antennas (important in a minute). All of this is much easier to find on a Windows PC or Apple device, but find it you must. And it shouldn’t take more than 5 minutes on the web. If you don’t know what your WLAN interface is capable of, you can’t tell if it’s living up to it’s potential. (Here’s one table that shows a bunch of Intel 11n adapters and what they can do. We care very much about that 1×1,2×2,etc. stuff, BTW.)
2. Now that you understand that wireless adapters can have huge differences in capabilities,and what yours is capable of you have one piece of the puzzle. (But just because my new Mac might be capable of a 1300 Mbps data rate, I shouldn’t expect to ever see that, and we’ll find out why in a minute.) The next thing you have to know is what access point/wireless router is in use. I might only get 5 Mbps during a speedtest with a wireless PC that is capable of 100x faster, and still have a perfectly healthy connection if I’m connected to old WLAN gear (and there is a lot of it out there). If you don’t know what your device and the network itself are capable of, you can’t know if you’re getting top-end performance.
   
3. Next- figure out where you are in the WLAN universe. Whether you use your wireless utility and the Network Management System (NMS) or AP/wireless controller interface, you can’t tell what a reasonable speedtest result is without knowing a bit about both ends of the connection, in terms of:
   – did you connect to the AP you think you should?
   – your data rate (.11a/b/g) or MCS value (11n or 11c)
   – your signal strength and quality
   – your retries (generally)
   – are you on 5 GHz or 2.4 GHz?
   – What channel width is in play? (20 MHz or 40 MHz)

On most laptops regardless of OS, you don’t have to work too hard to see what data rate your computer thinks it’s connected at. Remember- you’re seeing data rate here- NOT SPEED (again, we’ll get to the difference). Here’s a WIndows PC showing it’s data rate:

In “the system” from the infrastructure side, it looks like this (or some variation, depending on vendor and view):

In wireless, NOTHING is as easy as with wired Ethernet. Under “802.11 metrics”, to tell what the system thinks my client should be doing for speed, I need to understand that the numbers listed next to “Data RateSet” apply to 802.11b/g/a radios should the client need them. In other words, this client is saying to the AP that these are the pre-11n data rates it is capable of supporting. Note also, I have excellent signal strength and SNR, and that my retries (will ALWAYS be some on wireless) are low as a percentage of overall traffic. We also see that I’m in 5 GHz (11an), so on MY network we’re using 40 MHz channels, if the device supports it (all 5 GHz 11n or 11ac devices do, older 11a devices do not). We only use 20 MHz wide channels on 2.4 GHz regardless of 11g or 11n. Many 11n/ac environments will have the 40 MHz channel option disabled as a design choice, and you may need basic WLAN analysis software to tell what channel widths are in play if you don’t have access to the admin views on a given WLAN.

Then we see that the current transmit rate in use by my device is “m6”- but what does that mean?

HERE’S WHERE WE PUT IT ALL TOGETHER

Remember, my Nexus 7 is not MIMO. In other words, it’s a single-stream device. (2×2 and 3×3 MIMO clients would be 2 stream and 3 stream clients. We need that stream count knowledge to make decisions on whether we are getting the speeds we should!) Now, we need to consult a table for 802.11n or 11ac MCS values (they are not quite identical for 11n and 11ac) and figure out what we should see for a legitimate good data rate based on:

• MCS value
• Channel width
• Number of streams

(chart from WirelessLAN Professionals web site)

With my Nexus 7, using a 40 MHz wide channel, at MCS 6 and a single stream (because that’s all it’s capable of) I follow the red line into the two data rate values of 121.5 and 135 Mbps. The difference is whether “short guard interval” is in use, and that can be really hard to figure out if you don’t do Wi-Fi for a living. So lets’s just split the difference and say our data rate should be around 128 Mbps based on all of the parameters we can identify.

Let’s go back to this.

I’m saying our data rate should be around 128 Mbps. So why is our speedtest only around 70 Mbps on the download? BECAUSE IT’S WIRELESS! At best, for 11n and 11ac, you’ll get about 60% of your data rate as actual throughput. And guess what? 60% of 128 Mbps = 72.6. So we’re pretty close to what a perfect speedtest for MCS 6 should be FOR THIS DEVICE. Note that other MCS 6 values on the chart can go as high as over 1755 Mbps! That’s why you have to understand the specifics of each client device being used in testing if you are trying to base decisions about network performance on the results of speedtests.

TIP: In all practicality, if you take the time to master this methodology, if you realize 50% or better of an expected data rate during a speedtest, the network by this measure is generally fine.

But wait- there’s more!

So why did my Nexus 7 connect at MCS 6 for the faster test? It did so because I was fairly close to the AP and my strength and SNR were good. As my SNR decreases (because I get further away from the AP or because of interference), My MCS value will drop, and my speedtest results will follow- as reflected in the second test where things felt slower. But both were valid for the circumstances.

Use this methodology, please! 

This was a long piece, but the process is pretty simple at the end of it all. If you can digest and use this, you’ll make more realistic determinations about network problems, and you’ll also really start to understand Wi-Fi better.

If you do the exercise and get far less than you expect for a speedtest result, run it again. And again. Go at least 5 passes in case whatever server you’re using is getting creamed or some transient condition hit while you’re testing. If you are still getting low results after multiple passes, confirm them with another Wi-Fi client in case your first one has some oddity (driver wonkiness, OS updates in the background). And if both devices show less than expected… you’ve probably found a network problem. The bonus- you’ve done it methodically, and established a quality baseline to work the problem from.