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. 

[itdept_head_me]

Nope... not correct.......
I'm no apple fan boy...
One thing they do is stick to industry standards, unless the standard is poorly defined... then it's brue willis on steroids... patents to be grabbed...

I won't tell you the number of arguments i have had with apple internal staff over this..
(i don't mean the clowns at the "genius" bar.. but rather actual os programmers)

Where  the  stuff" does not behave inline with other manufactureres equipment....
only to be shown the standards..

I get just as much hassle from windows 10 users of wifi, but then again my environment is possibly one of the most polluted, poorly regulated environments.

I also worked with ruckus internal staff back in 2014 & apple over "sleep" issues related to apple products.& WIFI . and there was a hole in the standard.

but let's be clear.. much of this chaos is actually brordcom,
Apple don't write the wifi core & API that sits in the WIFI chips ,and one of the BIGGEST mistakes apple make in this area is that once a WIFI chip is in an Apple product, the likelyhood of a WIFI update to the core silicon FW is almost 0% (started to change on 10.14 & 10.15)

I have macs from the SAME batch with the same wifi chips but different BC firmware... that have "odd wifi" and you cannot update it,
This was so much of an issue that in the past i refused to buy apple kit unless i could find out the version of BC software on the chips.

[btt]

Lou, Caveman. Thanks, this is all very interesting feedback. Once I mentioned to the support engineer on my ticket that issues seem to impact mostly Apple devices he's suddenly gone somewhat MIA, so once I track him down I'll share what I learn. As far as Caveman's comments, I was seeing devices jumping SSIDs. In my case though I attribute this to user error, joining the wrong network, then joining the right one but not forgetting the wrong one. Once I removed the "wrong" networks from devices remembered networks that issue was resolved. Your comments on updates to the actual WiFi chips are also very interesting, I had no idea about that. Is there any way to actually check the version installed on a given Mac and then confirm whatever the latest actually is for the chip you have?

[itdept_head_me]

It's not the "APS" specifically, it is as if there is a fight between signal levels the device sees.
(specifically if multiple SSID's are on the SAME multiple AP equipment, registered to the SAME device AND "poor" overlapping of AP's', where the  SSID is in the devices access list)

to access the OSX data
About this mac->system report->wifi

10.14.6

  Card Type:    AirPort Extreme  (0x14E4, 0x134)
  Firmware Version:    Broadcom BCM43xx 1.0 (7.77.61.3 AirPortDriverBrcmNIC-1305.10)

similar mac
10.12.6

  Card Type:    AirPort Extreme  (0x14E4, 0x112)
  Firmware Version:    Broadcom BCM43xx 1.0 (7.21.171.134.1a2)

The "card types" are not always indicating a "different"  wifi board...,they are set to "tag" if a wifi board has been removed from one model range & placed in another....
Pfffff. Apple.....


We have a batch of 2011 mac air's all the "same" but the wifi FW is like a drunken hooker... all over the place.


All have the "latest" relevent os for the version. so fully updated 10.14.6, 10.12.6 etc
but still the FW is NOT synced... so any posts related to macs are likely to be  inconsistent.......


One of our factory sites covers several square KM.. so there is a  "lot" of opertunity for roming & handoffs...


I do a lot of work in  Asia /China, and as previously stated  the wifi environment is VERY hostile.
there is  a  "China" app with certain links. .. think tick tock ...
that gives you "free" wifi.

After an analysis of the app and the network traffic.. I found  that it actually "steals" every wifi pw entred onto a device via key logging.
Sends them to a "centalised" server along with MACS & wifi points seen
then as people "roam" about China, it install the wifi points & relevent pw's.

Wala... "free wifi",  but in doing so it is continually shoving in conflicting wifi  aps.
to the device.
ontop of this  we have the thousands of staff who think more is better, and have devices with several hundred WIFI acess points.

[btt]

So, update on this issue. I've continued working with Ruckus support, we don't have a resolution yet. I have narrowed down the problem a little bit more though. It seems the high latency only occurs in traffic from the APs going out to Apple wireless clients. Pings inbound from Apple devices do not have high latency, only when pinging an Apple device from something on the LAN. I did also observe some higher latency in pings to Apple devices from other wireless devices on the same AP.

Yesterday I tested using an AP in Standalone mode vs. one connected to our vSZ, it didn't really make a difference. For comparison I also tested a Unifi AP, it actually had worse latency than when using Ruckus. 

We've done heat mapping and yesterday I also walked around with a wireless analysis and troubleshooting tool, overall the wireless looks good. Signal, noise, and SNR values all in the green. There was some channel and not 802.11 interference detected in some areas, but the channels impacted by it none of the APs are using, so it shouldn't be an issue.

I'm fairly well stumped. I'm waiting to see what support comes back with next. 

Does anyone on here have any experience supporting the use of Lightspeed POS on their ruckus powered wireless networks? The only actual issue that is manifesting that the latency is being blamed for is with this POS system. Everything else that uses WiFi works fine. 

[itdept_head_me]

whats the ping like from the ruckus ap ?
if you go into the AP at the command line then run the ping from there?
Specifically the ap the apple device is "on"

it's odd, Im on 500's  & 1200 and  i am also seeing  something i had not seen before

from the airbook to the server

56 data bytes
64 bytes from 172.18.0.43: icmp_seq=0 ttl=63 time=1.400 ms
64 bytes from 172.18.0.43: icmp_seq=1 ttl=63 time=1.567 ms
64 bytes from 172.18.0.43: icmp_seq=2 ttl=63 time=2.206 ms
64 bytes from 172.18.0.43: icmp_seq=3 ttl=63 time=1.453 ms
64 bytes from 172.18.0.43: icmp_seq=4 ttl=63 time=2.275 ms
64 bytes from 172.18.0.43: icmp_seq=5 ttl=63 time=1.497 ms
64 bytes from 172.18.0.43: icmp_seq=6 ttl=63 time=2.863 ms
64 bytes from 172.18.0.43: icmp_seq=7 ttl=63 time=1.555 ms
64 bytes from 172.18.0.43: icmp_seq=8 ttl=63 time=2.639 ms
64 bytes from 172.18.0.43: icmp_seq=9 ttl=63 time=1.348 ms
64 bytes from 172.18.0.43: icmp_seq=10 ttl=63 time=2.113 ms
64 bytes from 172.18.0.43: icmp_seq=11 ttl=63 time=1.836 ms
64 bytes from 172.18.0.43: icmp_seq=12 ttl=63 time=2.031 ms


from the server TO the airbook
64 bytes from 172.18.0.211: icmp_seq=1 ttl=63 time=95.5 ms
64 bytes from 172.18.0.211: icmp_seq=2 ttl=63 time=14.5 ms
64 bytes from 172.18.0.211: icmp_seq=3 ttl=63 time=1.28 ms
64 bytes from 172.18.0.211: icmp_seq=4 ttl=63 time=59.7 ms
64 bytes from 172.18.0.211: icmp_seq=5 ttl=63 time=1.26 ms
64 bytes from 172.18.0.211: icmp_seq=6 ttl=63 time=104 ms
64 bytes from 172.18.0.211: icmp_seq=7 ttl=63 time=24.1 ms
64 bytes from 172.18.0.211: icmp_seq=8 ttl=63 time=1.49 ms
64 bytes from 172.18.0.211: icmp_seq=9 ttl=63 time=69.7 ms
64 bytes from 172.18.0.211: icmp_seq=10 ttl=63 time=92.1 ms
64 bytes from 172.18.0.211: icmp_seq=11 ttl=63 time=114 ms
64 bytes from 172.18.0.211: icmp_seq=12 ttl=63 time=1.51 ms
64 bytes from 172.18.0.211: icmp_seq=13 ttl=63 time=1.31 ms
64 bytes from 172.18.0.211: icmp_seq=14 ttl=63 time=81.0 ms
64 bytes from 172.18.0.211: icmp_seq=15 ttl=63 time=102 ms
64 bytes from 172.18.0.211: icmp_seq=16 ttl=63 time=24.1 ms
64 bytes from 172.18.0.211: icmp_seq=17 ttl=63 time=46.1 ms
64 bytes from 172.18.0.211: icmp_seq=18 ttl=63 time=69.3 ms
64 bytes from 172.18.0.211: icmp_seq=19 ttl=63 time=92.8 ms
64 bytes from 172.18.0.211: icmp_seq=20 ttl=63 time=114 ms
64 bytes from 172.18.0.211: icmp_seq=21 ttl=63 time=34.4 ms
64 bytes from 172.18.0.211: icmp_seq=22 ttl=63 time=1.44 ms
64 bytes from 172.18.0.211: icmp_seq=23 ttl=63 time=79.5 ms
64 bytes from 172.18.0.211: icmp_seq=24 ttl=63 time=101 ms
64 bytes from 172.18.0.211: icmp_seq=25 ttl=63 time=1.40 ms
64 bytes from 172.18.0.211: icmp_seq=26 ttl=63 time=44.9 ms
64 bytes from 172.18.0.211: icmp_seq=27 ttl=63 time=1.52 ms
64 bytes from 172.18.0.211: icmp_seq=28 ttl=63 time=89.1 ms
64 bytes from 172.18.0.211: icmp_seq=29 ttl=63 time=111 ms


from the AP to server
rkscli: ping 172.18.0.43
PING 172.18.0.43 (172.18.0.43): 56 data bytes
64 bytes from 172.18.0.43: seq=0 ttl=63 time=1.730 ms
64 bytes from 172.18.0.43: seq=1 ttl=63 time=0.491 ms
64 bytes from 172.18.0.43: seq=2 ttl=63 time=0.457 ms
64 bytes from 172.18.0.43: seq=3 ttl=63 time=0.542 ms
64 bytes from 172.18.0.43: seq=4 ttl=63 time=0.506 ms

--- 172.18.0.43 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.457/0.745/1.730 ms
OK

from AP to mac book air

rkscli: ping 172.18.0.211
PING 172.18.0.211 (172.18.0.211): 56 data bytes
64 bytes from 172.18.0.211: seq=0 ttl=64 time=38.039 ms
64 bytes from 172.18.0.211: seq=1 ttl=64 time=1.303 ms
64 bytes from 172.18.0.211: seq=2 ttl=64 time=46.987 ms
64 bytes from 172.18.0.211: seq=3 ttl=64 time=1.294 ms
64 bytes from 172.18.0.211: seq=4 ttl=64 time=1.300 ms



from computer to ap
ping 172.18.0.25
PING 172.18.0.25 (172.18.0.25): 56 data bytes
64 bytes from 172.18.0.25: icmp_seq=0 ttl=64 time=1.178 ms
64 bytes from 172.18.0.25: icmp_seq=1 ttl=64 time=1.237 ms
64 bytes from 172.18.0.25: icmp_seq=2 ttl=64 time=1.323 ms
64 bytes from 172.18.0.25: icmp_seq=3 ttl=64 time=1.863 ms
64 bytes from 172.18.0.25: icmp_seq=4 ttl=64 time=1.262 ms
64 bytes from 172.18.0.25: icmp_seq=5 ttl=64 time=1.294 ms
64 bytes from 172.18.0.25: icmp_seq=6 ttl=64 time=1.348 ms
64 bytes from 172.18.0.25: icmp_seq=7 ttl=64 time=1.945 ms


I think this is new...... or I would have seen it before..
i recently updated all my ap firmware via the 1200

it seems to be from the ap directly to the apple airbook
there are 3 computers on that ap with virtually no traffic.