High latency on Apple devices vs. Windows

  • 2
  • Question
  • Updated 2 weeks ago
  • Answered
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. 
Photo of BTT

BTT

  • 7 Posts
  • 1 Reply Like

Posted 3 months ago

  • 2
Photo of Lou Kalis

Lou Kalis

  • 24 Posts
  • 3 Reply Likes
I have seen something similar where a MacBook or ios device will be between two ap's and sometimes grab the closest one while the person passes it and then not roam to the next closest ap if the 1st one you passed is still holding a +70 or so db value.  I have also reported to this support who is aware and actively investigating.  Perhaps this is also your issue?  We are cloud-managed and leveraging R600's internally and T301S's externally.
Photo of Caveman

Caveman

  • 51 Posts
  • 6 Reply Likes
try taking a look at the  OSX battery/ power saving settings:

system preferenes->energy saver
try setting it all to "max" no sleep /no power save
"wake" for network access.
it "*might" be power save sleep, being woken by "wake for network access"


I was having such issues back in 2014, but now I see >150Mb/s from ruckus R500's to mac airs.
and switching between wifi points ... is spot on.... no flip flop.

but what i HAVE seen.. is multiple ssid's screwing things up, where the macs
"flip-flop" between other  SSID's that have stronger signals.

A situation can arise where it sees  another AP, sees the "wrong ssid" first then flips ssid even though its the same network.. running differnt ssid's, ESP. if there are 3rd party ssid's visible,  from what i have seen it looks like the apple wifi logic (in china we see hundreds if not thousands of SSID's where idiots have thrown on "burners")
(Edited)
Photo of Lou Kalis

Lou Kalis

  • 24 Posts
  • 3 Reply Likes
I do not have a work around yet.

While I see why those power savings might help, I'm in the same situation at BTT. We both have public customers accessing our "free" wireless. We can't be available to help everyone who wanders in at any time to make those setting changes.

Apple still insists on setting their own standards and forcing manufacturers to react to their products. This costs companies a lot of time and money to focus on apple alone. We had similar issues with Extreme Wireless prior pertaining to some products.

I have faith that the Ruckus dev team will solve this.

Please let us know when support solves the issue or offers a controller/ap update.

I hope this is solved quickly for you.
Photo of Caveman

Caveman

  • 51 Posts
  • 6 Reply Likes
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.
Photo of BTT

BTT

  • 7 Posts
  • 1 Reply Like
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?
Photo of Caveman

Caveman

  • 51 Posts
  • 6 Reply Likes
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.








(Edited)
Photo of BTT

BTT

  • 7 Posts
  • 1 Reply Like
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. 
Photo of Caveman

Caveman

  • 51 Posts
  • 6 Reply Likes
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.

(Edited)
Photo of BTT

BTT

  • 6 Posts
  • 0 Reply Likes
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.
Photo of BTT

BTT

  • 7 Posts
  • 1 Reply Like
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. 
Photo of Caveman

Caveman

  • 51 Posts
  • 6 Reply Likes
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




Photo of BTT

BTT

  • 7 Posts
  • 1 Reply Like
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. 
Photo of Lou Kalis

Lou Kalis

  • 24 Posts
  • 3 Reply Likes
Thanks for the update.