These Wi-Fi Retry Percentages Are Too Dang High (no really... Retry% statistics are often inaccurate)

 Show of hands: Who here has seen Retry percentages above 90%? If you work with Wi-Fi, your arm is likely reaching skyward as if you're hiding Darrell Lea licorice from the kids. (Hope you wore deodorant today.) Juniper Mist is most notorious for it. Nyansa Voyance -- which is no longer a Wi-Fi thing -- used to do it too. Aruba Central even has a built-in alert for it.

The problem is, 90% retries doesn't really exist (and of course, 100+% retries is impossible). When an AP repeatedly sends retransmitted frames (packets) to a Wi-Fi client -- and let's pause to point out that centralized WLAN management systems can only reliably know AP-to-client (not client-to-AP) retry statistics -- the AP will typically drop a packet before re-sending it so many times that the wireless retry percentage would ever truly hit 90%.

So why, then, do we see retry percentage near, at or above 90%? Because some (most?) Retry% calculations often use a denominator of successful frames instead of total frames.

At this point I must apologize for introducing Math into the proceedings without warning. Yes, we are tech people. No, that doesn't mean we want to deal with denominators and exponents and logarithms (oh my!).

Let's go through an example:

My favorite command when in an Aruba environment is show ap debug client-table. The command also requires an AP-name, so don't forget about that.

Here's an output of said command for your viewing pleasure (anonymized to protect the guilty):

The text may be a little small (though you should be able to click/tap to enlarge it), but the information can be useful. show ap debug client-table shows all client devices associated to a given AP, along with BSSID & SSID information, and... (drumroll, please) traffic stats! So much good performance troubleshooting info there, including stats on rates, frames (listed as 'pkts') and retries.

By the way... I'm not necessarily suggesting that every network engineer overseeing an Aruba wireless infrastructure should spend their days running the show ap debug client-table command. It only shows info from one AP at a time, and that info only reflects a moment in time. Some of these stats may reflect prior conditions, when the Wi-Fi environment around this AP was better or worse than it is now.

With that said, show ap debug client-table is a darned good indicator of whether an AP and its associated clients are likely to experience great Wi-Fi. Wireless Retry% is one of THE top indicators of Wi-Fi performance, alongside physical indicators such as distance from the AP, number of in-use client devices nearby, and signal strength (RSSI).

Looking at the output for show ap debug client-table, it can seem pretty simple to get a retry percentage for a given client: Take the number in the 'Tx_Retries' column, divide it by the number in the 'Tx_Pkts' column and voila!, Retry%.

Or is it?

Take a look at the 5th client device in the above screenshot; the one with a MAC address ending in ea:64:11. That client shows 8 under Tx_Pkts and 30 under Tx_Retries, which would result in a Retry% of 375% using a basic 'retries divided by packets' calculation. Nothing in life or nature can be a subset of something and be over 100%. 

The flaw here is, the number of retransmitted frames is being divided by the number of successful frames, not the total number of frames. To get the total number of transmitted frames, one must add successful frames with retry frames. Or...

Retry% = Tx_Retries / (Tx_Pkts + Tx_Retries)

That formula will result in the true Retry%. Using our above example of the 5th client device, the Retry% would be 30 retries / (8 successful frames + 30 retries), or 8/38. That's a Retry% of 79%. Still high, but possible. And not the over-100 percentage which would be shown/indicated/alerted in centralized Wi-Fi management systems.

The example I'm giving is from Aruba. But I can tell you Juniper Mist calculates Retry% the same way. (I am less certain about Cisco, Extreme and other enterprise wireless vendors; I just haven't dove into their raw retry data just yet.)

What can be done about the inaccuracy in Wi-Fi Retry% statistics?

The first thing to note is, by the time you read this the Retry% stats may have been fixed. You may have noticed in the first paragraph it says Nyansa Voyance used to calculate retry percentages inaccurately. That's because in 2019 -- before Nyansa was acquired by VMWare and Voyance was repurposed as a centralized SD-WAN performance analysis system -- your humble author notified Nyansa of inaccurate Retry% calculations and they fixed it.

If your centralized Wi-Fi management system's software hasn't been fixed and is currently showing retry percentages above 100% (or getting regular alerts for retry percentages at or above 90%), the the way to get the true Retry% is to take a page from wedding invitations and be a Plus-1 person.

What 'Plus-1' means is, add 1 (which means 100, since we're dealing with percentages) to the Retry%, then divide the erroneous Retry% by the Plus-1 percentage.

For example: If your centralized Wi-Fi management system shows a Retry% of 15% (15 retries for every 100 successful frames), the real Retry% would be 15/115, or 13%. Just take the percentage shown, and divide it by that same number plus 100.

As you may be able to tell by looking at the above example, these Retry% miscalculations aren't a super-big deal. Yes, 15% is higher than 13%, but does that difference change one's perception of Wi-Fi performance? Probably not... because both are bad. 😎

Sorry, it's the truth (at least from what I've seen). And I'll write more about Retry% and other Wi-Fi performance topics in the future.

*** 

Ben Miller has worked in Wi-Fi for wayyyyyyy too many years. (Over two decades now!) You can contact Ben via email or follow him on Twitter, using the contact information below. 

If you like Ben's blog, you can support it by subscribing and by shopping through his Amazon link.  

Thank you. 

Twitter: @benmiller 

ben at sniffwifi dot com