HW072: Wireless-Adjacent Products from Digi International
Digi International has a whole lot of things that aren’t exactly in the Wi-Fi space, but are close enough to be of interest to WLAN engineers. Joining us today to talk about Digi International’s wireless tech, and what it means for wireless LAN pros, is Bob Blumenscheid. Bob discusses Digi’s offerings, including their XBee modules, low-power RF solutions, IoT solutions, and the transition from SIM to eSIM technology.
Listen here: https://packetpushers.net/podcasts/heavy-wireless/hw072-wireless-adjacent-products-from-digi-international/
Why Speed Tests Don’t Measure Wi-Fi Health
Ferney Muñoz | WLPC Phoenix 2026
Speed testing is one of the most common client requests Wi-Fi professionals receive. This talk covers four specific problems with using throughput testing as a measure of Wi-Fi network health, with examples from real deployments and packet captures.
Active surveys reflect the client device, not the network
A school deployment — Willow Canyon Elementary. An active survey flagged Room 109 as a problem: 1 Mb/s throughput during the walk. Switching to signal strength showed five access points in range at -58 dBm or better.
Throughput heatmap showing Room 109 in red — 1 Mb/s actual data rate at the time of the survey. (~2:26 in the video)
During the survey, the client device was associated to an access point in the media center 34 meters away — going through walls, doors, and bookshelves — connected at -74 dBm.
The same pattern repeated across the building. Room 122 appeared as a problem, but the device was 32 meters away, associated to an AP on channel 52 at -75 dBm, despite an AP in the same room at -20 or -21 dBm. The entire orange area on the survey traced back to that same AP on channel 52.
“No bad places. I just had bad time when I was doing the survey.”
The client device makes the roaming decision, not the surveyor. Low throughput at a location during an active survey reflects what the client chose to do at that moment — not the capability of the network at that location.
Speed test servers are not where your applications go
Traceroute showing speed test servers in Salt Lake City — a couple of hops away — with 4 ms and 11 ms round trip times. (~9:01 in the video)
Running speed tests in Salt Lake City, the test was hitting UEN speed test servers right in the city — 4 ms round trip to one, 11 ms to another.
“That sounds kind of deceitful because it’s giving me the impression that I’m getting this awesome speed and really, really low latency because it’s a server at the ISP location.”
The actual application traffic from those same classroom devices was going somewhere else: Cisco WebEx sessions to San Francisco, Kahoot to an AWS data center in San Francisco, Zoom servers, Microsoft sessions to Seattle. In a separate example from Cleveland, Apple services were going to San Francisco, Netflix to Washington, WhatsApp and Meta to Ireland.
The difference — potentially around 20 ms additional latency to reach those real-world destinations — could be the threshold that results in a disconnected phone call.
Speed tests saturate the shared medium
In a real classroom: 63 Chromebooks connected and doing normal work on one radio. Channel utilization was at 53%.
63 devices on a single radio, 53% channel utilization during normal classroom activity. (~8:26 in the video)
Running a single speed test against a WLAN Pi plugged into the data closet brought channel utilization to 100% — high duty cycle.
“Literally garbage traffic. We’re putting garbage in the network because it’s just random bits — big big stuff that is being put in the air.”
A real-world example from the talk: a conference network deployment where the client's acceptance test was 30 staff simultaneously running speed tests on laptops and phones.
"That doesn't prove anything."
The packet capture: what a speed test actually generates
Packet capture showing iPhone on Zoom (flat, ~200 pps) vs. Windows and Samsung devices running speed tests (peak 17,190 pps). (~17:00 in the video)
A phone running an active Zoom session alongside two devices running speed tests. The Zoom session required around 200 packets per second throughout.
When the Windows device started its speed test — 33 seconds of upload and download — it generated around 434,000 packets. Packets per second peaked at 17,190. Adding the Samsung device brought the total to over half a million packets.
The two speed test devices generated 87.6% of all traffic. The data actually required to keep the Zoom session alive was 2.4%.
“Why do you have to generate millions of packets per second when all you need to have a good healthy connection is under 200, 300 packets per second per device?”
When speed testing is valid
Speed tests have legitimate uses: testing a backhaul, verifying a 10-gigabit port delivers 10 gigabits, confirming rate limiting is configured correctly. "There is a use case for that."
“It doesn’t make any sense in my little Colombian mind to just keep pushing traffic over and over and over and over. What are you trying to prove?”