• Hi guys, just working through the CWAP book and I often find myself delving further into certain topics which is the sign of really good study material :-)

    I read about retries and wanted to see what I would see in 'real life'. I understand/appreciate what the text books say about < x% of traffic should be retries for application y, etc, but what do we really see???. Instead of performing an manual Active survey I decided to passively sniff a specific ESSID, BSSID and channel to see what amout of traffic for a specifc AP/ESSID was retries (using Wireshark). The test environment was an office, nothing unusual but with a seperate floor operated by a second company.

    Over a 3 hour spell, the number of retries was 49%! I was quite surprised by this, but users of this AP/ESSID combination were happy and no-one had complained. I did some Googling and it seems that seeing over 50% of traffic being retries was not so unusual - even more strange is that users remain happy.

    Just wanted to hear what other people who have performed similar testing saw for retries? Are retries as big a deal as some people make out?


    Note: Before someone chimes in with 'There will always be retries........' or 'Retries are part of life in WLANs....'  I understand and appreciate there will NEVER be a case where there are 0 retries over a period of time.

  • By Howard - edited: September 2, 2014

    What kind of traffic are we talking about?

    Web surfing, VOIP,... ?

    The default number of retries on my Cisco AP's is 64.   I work in a very AP congested space and once, just to see the effect, I set this limit to 6 retries - But I saw no difference.    This was with multiple 2MB downloads to the clients.

  • How happy the users are depends on what they are trying to do? The higher retry rates would be insufficient if you were doing voice or streaming media. I would say 6 % or retries for such application that are latency sensitive. Period of sniff would also be a factor. For stream things through a web browser, some browsers will compensate for latency as well. Browser selection important qualification as well.



  • Mark,

    Do you have any statistics or suggestion for particular browsers ?

  • Hi guys, thanks for the replies. The applications were standard data - web browsing, email, etc - NO voice or video. The retries % was based on ALL users that were connected to an AP as I wanted to get a broad feel of retries within the BSS.



  • Darren,

    I am guessing that is why your users do not complain. When you are doing basic tasks wireless performance if not frequently complained about, users are just happy they have wireless.

    Thank you,


  • Anything other than IE is generally a safe bet. Chrome and Firefox seem to render video better in higher latency environments.

  • Thanks.

    I guess I should have known.  

    My company forces us to use IE with almost everything. 

  • Thanks guys.

    Keen to hear if anyone has taken the time to sample the % retries for a given BSS over a period of time? I plan to take a similar sample from my home, just to compare what I get there.....

  • Ok, so I was actually running 2 different packet captures, from 2 different laptops on the wireless at my office for approx 6 hours today, for a completely different reason. 1 of the packet captures was 2.4GHz and the other 5GHz. 

    The 2.4 GHz retry rate was only about 2%

    The 5GHz retry rate was less than 1%

    The retries where appeared to happen primarily when I found myself roaming between APs. When I was stationary it rarely happened. 



Page 1 of 2