nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

High latency on Apple devices vs. Windows

unknown

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.

Find more posts tagged with

Accepted answers

All comments

unknown

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.

unknown

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?

itdept_head_me

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

unknown

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.

unknown

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.

unknown

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.

unknown

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

unknown

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.

unknown

Thanks for the update.

unknown

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

unknown

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.

unknown

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.

itdept_head_me

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....

technology_dep1

Hi William,

I have experienced similar issues as your in our 58 AP deployment. I'm wondering if you have made any recent progress you'd be willing to share?

Thanks,

Justin Hayes

unknown

Justin,

Unfortunately no meaningful progress has been made from my last update. I've had multiple calls with my sales engineer, my account manager, and the support engineers working on this. For the last few months it's just been this loop of engineering requesting testing from support, support providing it or having some issue providing it requiring rework, and the loop then just continues over and over. As of right now I'm not to thrilled with how things are going. They still acknowledge the issue, that it's in their equipment, and they're working to figure it out.

unknown

Long story short, +1 on this problem. We have been experiencing random latency with Apple MacBooks. Pings go all over the place from the device to the Internet or gateway. Pings to the AP are solid.

unknown

So I've had an update from the engineering team, via the support engineer I'm working with.

It seems that they believe the issue is how Apple handles powersave mode on their device wireless NICs. Engineering is claiming that high latency coincides with when the wireless NIC on the Apple device enters powersave mode and the AP has to buffer packets. I've asked them to troubleshoot further and get Apple involved to see what can be done.

I've included the short report engineering sent me attached to this post as images. It provides some explanation of what they believe they've found, along with some packet capture data.

We'll see where this goes next....

Image_ images_messages_6037b520129ce112e92b9b7f_51d7031b8237279774006aff216180e5_RuckusReport1-e9dda858-b2bb-45c3-b12c-2f4679bd2061-564154225.png

Image_ images_messages_6037b520129ce112e92b9b7f_e70978870f34797f557292096d37d7e4_RuckusReport2-568acf62-ef66-4242-a3f8-01a645889ad4-563230704.png

Image_ images_messages_6037b520129ce112e92b9b7f_a8c10c9159bdb1e659c8f9427519c7eb_RuckusReport3-59483529-1776-4b66-b7b9-14e700c842b1-562307183.png

itdept_head_me

Apple are unlikely to assist in this , since it will seriously affect their "power save" and battery lifetime figures.

it's all about looking good in the sales literature, not performance under real world conditions.

Sadly it is not the only thing that is going on at Apple.

unknown

That is my fear, but I'm going to keep pushing.

unknown

Any updates?

unknown

Sadly, no. I've largely given up on resolution at this point. My customer ended up hard wiring all their POS iPads and giving up on the mobility they had originally wanted for their food service staff. It's extremely frustrating. Ruckus is claiming that their latest update to the virtual SmartZone software clears up the latency being seen due to the power management, but latency is still high.

I'll likely look for solutions from other manufacturers for future deployments if I know Apple devices will be in heavy use for critical applications ahead of time.

WesZDept

It's been a while since this post was updated, but we encounter the exact same issue's already for some years and seemed to be increased with newer versions of MacOS.

Windows laptops in our network don't have any problem, also being connected to the same SSID.

@AnonymousI was wondering if you ever tried a non-Apple device (Samsung Tablet or something) to see if that is performing better that an Apple device.

btw, we are not using Ruckus but we are using Extreme Networks (switches & ap's) but we face the exact same issues.