High Latency for MR42 AP (MR 26.6.1 firmware) Motorola Scan Guns

[Echopath]

We have a warehouse deployment with 4x MR42 APs. We have the Motorola scan guns isolated to their own SSID running only on 5GHz. All 10 scan guns show very high latency when pinging the local gateway IP on the network. Seeing average latency of 90ms, highest ~200ms, best is 28ms and this is all on the same network. When I put my laptop on the same network, I'm getting 3-5ms pinging the gateway. Latency does not seem to stabilize much when scan guns are near to serving AP.

Performed wireless survey of warehouse area. Freqency and power planned to minimize interference, so surveys look good. I'm not seeing much external 5GHz interference. Using 20Mhz channel widths. We were not noticing these issues a few months prior.

I have other deployments of similar scan guns running on Meraki with same firmware but model APs. Trying to isolate the issue between a wireless issue or a scan gun hardware/software issue. AP utilization looks to be good. From controller, ping response show similar results as reported above with 0% loss rate.

Any suggestions on troubleshooting or isolating the issue would be greatly appreciated.

[PhilipDAth]

Is this actually causing an issue? 

It sounds to me like the motorola's are negotiating a power saving mode to use to conserve battery when traffic volumes are low.  Specifically they are polling between sleep states. 

You could look at the power save settings on the motorola's if you are more concerned about latency than battery life. 

[cmr]

I'd agree with @PhilipDAth , all the latency issues I was seeing on MR55s and 27.x were down to power saving.

[Echopath]

We went through and disabled all the power saving settings on the device. I can ping from the device and the pings aren't lost, just very high latency. I would think if it was going into power saving mode, then I would start to drop packets or see disassociation from the AP.

[PhilipDAth]

Nope.

Your device is probably using "Wifi Power Saving Mode (PSM)".  With this the device tells the AP it is going to sleep (for say 100ms).  The AP then buffers all the packets.  The device then says "I'm awake now", and sends those packets.

Zero packet loss, just much higher latency but makes batteries in portable devices last much longer.

The other mode is CAM - constantly awake mode.  This is what your notebook will be using.

[PhilipDAth]

ps. Devices can also flick between the modes on the fly.

[Echopath]

I double check the Wireless LAN Profile setup on the scan guns. Under Battery Usage Mode: there are three options:

• CAM
• Fast Power Save
• MAX Power Save

This is the setup in the Fusion software. We have Fast Power Save enabled. You are suggesting that we go to CAM which is "constantly awake mode", correct?

[Echopath]

I did find on a post on the Zebra site https://developer.zebra.com/thread/31921  which suggest CAM only as a troubleshooting method. One post states it as follows:

"The only time I have found that CAM mode helps is when the APs do not play well with the power saving schemes on the device.  CAM mode is a good test if you are having network issues.  If it fixes a problem,  it's worth investigating to find out why.  There may be some AP settings or firmware updates for the APs or the device that might make power saving mode work properly.  I try not to use CAM mode in production unless it is the only way to make things work."

I'll enable CAM and test to see if it yields better response times. If so, then I'm back to what the above quote suggests which is Why? Why aren't the scan guns and APs playing well?

[PhilipDAth]

Is the latency actually causing a problem?

If it is a power-saving issue, then CAM should fix it.

I don't agree with the post however.  The client has to request the power saving mode.  If the AP is capable it can agree, and then it needs to buffer the packets.  The AP firmware should not have much impact on the client making the request, or the amount of time that the client is requesting the sleep period to be.

If you do use CAM mode expect their to be an impact on battery lifetime.

[Echopath]

@PhilipDAth The latency does seem to be causing issues. The scan guns are running a RDP connection to our ERP software off-premise, so round trip we are often seeing 135-250+ ms avg ping times to the server with ~75-80ms avg response times just getting to the gateway across the wireless network. Again, the connection is all over the place. The users are getting many disconnects/reconnects. Many pauses when they roam from AP to AP within the warehouse, but very low bandwidth utilization on the system.

The fact that I have high latency just to the local gateway with the scan guns but no other devices indicates a wireless issue with the scan guns. We have another location using similar hardware connecting to the same server who are not experience issues. Since it is a remote site, its taking some time to get a user to run similar testing for me there as a comparison (pings to gateway for example).

[Foxo]

Are you still having this issue and have you done anything to resolve it?

We have some Intermec/Honeywell scanners + ARM based devices and an update to 26.6.1 appears to be causing a similar issue - loss of WiFi signal, RDP connections freezing and disconnecting, and high latency. 

We're considering rolling the firmware backwards as a temporary fix since it is impacting our business. 

[NolanHerring]

Are you able to test it on 26.8.1 and report back

[Echopath]

We switched two guns to CAM mode. The battery only lasted 2-3 hours each time, but we did not have the disconnects like we were having. Since I was not onsite, I was unable to test the latency from the gun like I did before which will have to wait until I'm back onsite in a couple weeks.

We are also switching an additional gun to CAM mode to broaden our testing. The preliminary test results do seem to indicate that CAM does improve the user's experience.

[cmr]

@Echopath the issue I was having it was seen by simply unplugging the power supply.  This caused the Windows power profile to change and in the battery profile an element of power saving was enabled.  Within 5 seconds the pings went up massively,  no idle time!