Skip to main content

9 Messages

 • 

182 Points

Wed, Jul 29, 2020 7:03 PM

Answered

High latency on Apple devices vs. Windows

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. 

Responses

25 Messages

 • 

384 Points

4 months ago

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.

9 Messages

 • 

182 Points

That could be related. The area of the property where we're focusing our troubleshooting efforts had two APs that clients could roam between. We've temporarily disabled one to force all clients on to one AP and we're still seeing the issue. Have you come up with any workarounds or tweaks that have helped your situation?

63 Messages

 • 

872 Points

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")

25 Messages

 • 

384 Points

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.

63 Messages

 • 

872 Points

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.

9 Messages

 • 

182 Points

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?

9 Messages

 • 

182 Points

3 months ago

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. 

63 Messages

 • 

872 Points

3 months ago

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.

9 Messages

 • 

182 Points

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.

9 Messages

 • 

182 Points

3 months ago

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. 

63 Messages

 • 

872 Points

3 months ago

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




9 Messages

 • 

182 Points

2 months ago

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. 

25 Messages

 • 

384 Points

Thanks for the update.

1 Message

 • 

10 Points

We are having a very similar issues with Apple devices on our network at campus and still have not found a resolution. 

9 Messages

 • 

182 Points

It's funny, I just got the notification of your comment, right after I got off the phone with my sales engineer. I don't have any real meaningful updates, but I'm about to post what I do have.

9 Messages

 • 

182 Points

7 days ago

Hi all. Another update since my last one. The private build I mentioned previously never came my way, support told me in their testing it didn't resolve the issues. Support has opened an engineering request and the issue is now on their plate to figure out. From what I've been told, they've narrowed the issue down to some sort of problem within the actual Ruckus AP where the traffic passes from the APs ethernet interface to it's wireless interface. They're seeing high latency introduced at that point, and they're trying to figure out why. Engineering has apparently been working on this for several weeks and I've not received a meaningful update beyond this since then. I've been hounding my support contact every couple days to see where we're at. My Ruckus Account Manager and Sales Engineer are involved now as well, so we'll see if that yields anything useful. Hopefully I have some positive news soon, but I'm not holding my breath.

63 Messages

 • 

872 Points

7 days ago

ruckus are top hole on sorting things out....

It's the only reason i use their kit...... sometimes it takes them a bit longer but they get there eventually....