Americas

  • United States
gthill
Contributor

Is Wi-Fi throughput testing useless?

Opinion
Oct 25, 20174 mins
MobileNetworkingSmall and Medium Business

We need a lot more than the data points Wi-Fi throughput testing generates for us.

abstract wireless communication network
Credit: Thinkstock

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.  

It’s not. 

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.

+RELATED: What is MU-MIMO and can it boost Wi-Fi capacity?+

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:

  1. Design a Wi-Fi network with planning software;
  2. Deploy the design;
  3. 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.

gthill
by GT Hill
Contributor

GT Hill is currently the Director of Product and Technical Marketing at Nyansa. He was formerly the Director of Technical Marketing at Ruckus Wireless. He has been working with Wi-Fi since 2002 when he started a Wireless ISP covering over 1000 square miles in rural Oregon. Since that time he became Certified Wireless Networking Experts (CWNE) No. 21, has been an independent consultant, and worked for various technology vendors. He currently resides in Arkansas on his decommissioned Titan II Nuclear Missile Base.

GT’s extensive understanding of computer networking includes Wi-Fi protocol behavior, network architecture and specialized topics such as dynamic beamforming, 802.11n and RF interference. He has successfully designed Wi-Fi networks in various environments, and trained company personnel to maintain and troubleshoot the network. GT has also implemented many successful Wi-Fi networks in varying environments from State Capitol buildings to covering 1000 square miles of the high desert for remote Internet access.

GT’s strength lies in his ability to take increasingly complex and technical topics and successfully communicate their value and operation in simple or deep detailed terms.

The opinions expressed in this blog are those of GT Hill and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.