Ping times to Andoids/Iphone from Meru WiFi

[twin--turbo]

Can anyone with a Meru Network, Especial with 320 AP's

Try a ping from your desktop to an Android Device(s)...

Would be interested to know the results.

Rob

[synaesthesia]

Pinging to nearly any wireless enabled phone (android, IOS, RIM) will get you seemingly random results on any controller - usually between 10 and 1000ms, regardless of where the device is.

[twin--turbo]

is there a reason? I could not find anything relating to it on tinterweb.

I have had a support case open for a few weeks regarding this, it makes our SIP clients on phones unuseable.

I get more stable and lower avg pings to a vpn client on the phone over 3G

Rob

[psydii]

Pings and ARP requests often get buffered by the controller when the mobile device in a powersaving state and only forwarded on when the device wakes up, usially when the timer for these sorts of things on the controller expires.

What version of SD are you running?

Also is there any chance that the communications is making use of UDP Broadcasts? A video app recently caught me out there.

[twin--turbo]

Nope,

Sat there for 500 pings, no apps running but swiping the screen to keep the phone live..

SD?

Rob

[psydii]

Just because the screen is on doesn't mean the radio isn't powersaving. The technology is called U-APSD. I do not fully understand it.

SD = 'Meru System Director' the OS of the controller and APs.

My iphone ping responses range from 4-200ms. A few moments after the screen goes to sleep the IP stack stops responding to pings, it will then wake up every 1-2 minutes for about 30 seconds. Interstingly an incoming skype call will wake the radio and the phone when a ping gets no response. I would suggest that this behavoiur is the controller only passing packets to the radio that are important. ICMP is not important. In a similar vein I have read that pinging your core switch/router is no way of looking for anything other than 'is it on' diagnostics as the software running on the device treats ICMP responses as pretty much the lowest priority and so even on an only moderately busy network responses might seem to have an unexpected level of latency, that is not indicative of network performance.


I would suggest that framing the problem as 'long ping times are causing sip to be unreliable' may send people down a blind alley when it comes to resolving your actual problem: 'SIP is unreliable'. If you've had the network configured for VOIP & SIP, then you probably need someone to take some packet captures for analysis. If you haven't got SIP configured and the system you are using is not covered by the Meru Configuration guide then, again, you probably need someone to take the captures and traces and analyse how your system needs to be tuned.

[twin--turbo]

Ahh, we upgraded SD to the latest release a couple of weeks ago to try and resolve the issue.

the ping response we get range from a lucky 4ms... to a normal 300+ up to 2ms or a total drop. and avarage in the high hundreds.

Pinging one android to another (as an ap) sees avarge pings arround 115ms.

Rob

[psydii]

Don't forget that meru does funky over the air traffic management, delaying some packets and prioritising others even before you look at the configurable QoS options.

I wouldn't be too concerned with ICMP - concentrate on what your VOIP traffic is doing. If you are seeing general connectivity issues from the devices (i.e they work well on home wireless but not in school) then one question to ask is: do you have the Client Locator script configured for them?

You can do some crude connection analysis by taking a look at the 'station log' for the devices. there should be minimal handoff between APs for static devices, and authentication should only happen very occasionally.

What release do you believe to be the latest? It is an ever changing target. We're running a release from a few weeks ago that isn't listed, and I know there are later ones. Everything is rock solid for us now, but no Andriod deployed.

[wotnowires]

Hi there,

Just had a good look at this, and I am reasonably confident that the issue you are reporting is to do with WiFi powersaving on the iOS device.

Just tested on my own client, and I see high ping times, however if I then start streaming video these pings drop to a more reasonable 5-10ms consistently.

With legacy WiFi powersaving, a Station (wireless client), is able to indicate in each packet if it is going to go to sleep. When in a sleep state, an AP is only able to wake that client once per DTIM interval (usually one beacon or 100ms by default). The AP indicates in the TIM portion of the beacon (which the client wakes up to listen to) that it has data waiting for the client. The client then wakes up and sends a PS-POLL frame to the AP to indicate it is ready to receive any buffered data.

As there's only the opportunity to wake a client once per 100ms, this will easily show an increased ping of 100-200ms (dependent on how quickly the client can wake, get access to the medium, send a PS-POLL and then have the AP schedule and tx the buffered data).

Hope that makes sense?

Kind regards,
Paul.

[twin--turbo]

But we can ping Android-2-Android with acceptable(ish) rates that are fairly steady. Hence I am not convinced the wireless is going to sleep.

Rob

[wotnowires]

Rob,

The Android devices will likely use a different algorithm to determine when to go to sleep. - Maybe less aggressively.

I just tested this with my iPhone and saw my ping drop to a steady 2ms as soon as I started to stream from iPlayer.

A packet capture shows the device indicating that it will go to sleep regularly.

Kind regards,
Paul.