High latency on Apple devices vs. Windows

[btt]

New to Ruckus and working on a deployment for a hotel/resort property. We've gotten reports of connectivity issues with the POS system that runs on iPads carried around by the servers. I did some digging and I noticed high latency spikes when pinging the iPads. Pings will sit below 10ms for maybe 10 pings, then bounce up anywhere between 50-250ms for another 10 pings or so, then come back down, with some variations. I'm able to reproduce this issue with Apple laptops as well. We've done a site survey, signal and SNR values all look good. What's odd is on Windows devices I'm not able to reproduce the issue. A windows devices connected to the same WLAN on the same AP as a Mac device will maintain low latency, while a Mac or iPad will spike. 

I have a case open with support, but I wanted to see if anyone had any suggestions/tips on things that can be done from a config standpoint to try and make Apple devices happier. I'm running the latest version of the vSZ and using R720s and T710 omnis. Thanks. 

[btt]

Caveman, I think you've successfully reproduced my exact issue! The only step you did that I haven't is run pings from the AP to the Apple device, the reason being all my APs live on a management VLAN that can't talk to the VLANs associated with my WLANs. I think based on your feedback though I'll put a testing WLAN on my management VLAN and do that part of the test. 

I'm curious, how are you managing your APs? I use virtual smartzone essentials running version 5.2.0.0.699. This is a new controller that was installed at that version. Firmware version on all the APs is 5.2.0.0.1412.

[btt]

So I shared this newest information with my contacts at Ruckus, it looks like they may be opening a bug report. I'll keep this thread updated with progress. Big shout out to Caveman for testing and replicating my issue, much appreciated. 

[itdept_head_me]

back in 2014 we purchased a 1200, what is now a 1205, and life & ping's were good
after leaving , it was mismanaged into the ground....
so when i returned , i updated to the latest FW and assumed it was fine.
what ever is the latest version of 1205, issued 2 months ago

As regards "vlan" , just set your computer to that vlan & plug into the switch... or plug one AP directly into your computer.

I have some idea that ruckus cannot fix this issue...,..
becasue if i was apple.... ........
i would only scan the wifi 50% or less of the time looking for a "connection packet" , thats a 50%  or more saving on the power for WIFI....   notice how symetrical it looks.

I also have some idea that maybe there waa a discusison with an Apple engineer back in 2014 about such dirtyness..... and maybe an old "fix" has been removed in recent kernels...

i think what we are seeing is a "wakup" and timed window scan, so if it is a steady speed of packets it ramps up.
(this could be tested by doing a very big file transfer & a ping)
and if it is not a steady stream in the window, it goes back to a 50% scan

sadly the ruckus AP ping is half assed....., you cannot  make packets bigger or faster.
so i cannot test my idea.....

maybe you can play about with the ping timing on your workstation, try  100ms & 50ms
or 0.1 & 0.05 of a second

[btt]

So I know this has sat quiet for awhile, but I don't want to be the guy who lets a thread die without update/conclusion.

I've been working with Ruckus Support since I originally posted this thread. It took many weeks of testing/troubleshooting over the phone, but I finally got far enough that they took backup copies of my vSZ and spun it up in their testing lab and they were able to reproduce my exact issue with APs and Apple devices in their lab. At this point I've been told engineering has come up with a private build of the vSZ firmware which is suppose to address the issue. I'm waiting to hear back on how testing that build is going, then I'm assuming I'll be asked to update my controller to it at some point. I'll update this thread again once we've made more interesting progress. 

[lou_kalis]

Thanks for the update.