Throughput testing has long been regarded as the best way to find great Wi-Fi products, validate WLAN design and troubleshoot user Wi-Fi issues.
Wi-Fi throughput testing generates a single data point under a specific scenario in a highly dynamic environment. That’s it. In today’s enterprise network environment, we need a lot more than that.
It’s tempting, for example, to use Wi-Fi throughput tests to evaluate vendor equipment by determining the maximum TCP data rate (or speed) that, say, an access point can achieve with one or more client devices concurrently connected. But these tests don’t really reflect reality because you won’t see how that equipment really measures up until you have the network fully loaded and deployed.
The same thing goes for Wi-Fi network design. Throughput testing is often called on to confirm the design of wireless LANs. Here’s the typical drill:
- Design a Wi-Fi network with planning software;
- Deploy the design;
- Perform coverage, signal and throughput tests.
If you have decent signal strength (e.g. -65 dBm) you’ll get good single client throughput results. But this doesn’t show you how the network will actually react when things get busy.
The way to properly test Wi-Fi networks is when the system is loaded. This means multiple clients connected and sending data through multiple APs. This is rarely (read: never) done as a post installation check because it’s too difficult, time consuming and cumbersome.
Another common use case for field throughput tests is troubleshooting Wi-Fi client problems.
But one of the notorious problems with Wi-Fi throughput testing is the inability to quantify the actual performance experienced by users. It’s sort of like dropping hundreds of needles twice and expecting them to land the same way. Wi-Fi is simply too dynamic a medium to reproduce many issues. Even if it were possible, it would require an army of people to troubleshoot and track down one user’s problem.
While most Wi-Fi engineers will admit that using throughput testing as a troubleshooting tool has limited value, they don’t know what else to try.
But there is a better way.
The networked world has begun to believe the best way to accomplish these tasks – evaluating equipment and network design and trouble shooting end user problems – is to tap into the data already running over the network. And they’re right. The answer is in the user experience.
Whether users know it or not (OK, we know they don’t know this), the wireless network experience is inextricably linked to how the wired network, network services and applications are interacting with the myriad of client devices in use on the corporate network.
The key is to start with how the client is interacting with the Wi-Fi network, baselining this interaction and watching it ebb and flow as you make changes to the network.
Collecting, analyzing and correlating information from WLAN controllers and client network transactions will give you a much better understanding of how the Wi-Fi network (the equipment and the wireless design) is actually performing under load. Today this is typically a tedious manual process reserved for data scientists that companies can’t afford.
This is where the power of cloud computing really helps. Clever enterprises have begun siphoning client transactions off the network and pushing it to the cloud where the data can be more efficiently processed and correlated. Their goal is to quantify users’ actual network experience on any device using the volumes of network data already in their possession.
How did user devices perform when you changed a Wi-Fi setting, moved an AP, changed AP power settings or upgraded AP models? For many, network data has become a single source of truth for answering such questions.
In this context, user client devices effectively become Wi-Fi sensors. When you take into account the WLAN controller, the network service and real application data, you have a much clearer picture of client performance over a Wi-Fi network. One that has real meaning to network operators.
Think about this as a new and better way to actually quantify the Wi-Fi performance that clients are experiencing without all the pain, anguish and ambiguity you’ve experienced using conventional Wi-Fi throughput testing.
This article is published as part of the IDG Contributor Network. Want to Join?