BW16 ping latency

Technical Support
1

I have a BW16 with an Arduino sketch to initialise the WiFi, running on the same Wireless Access Point as my development machine.
When I ping the BW16, I see very variable ping times, for example:
Reply from 192.168.100.44: bytes=32 time=82ms TTL=255
Reply from 192.168.100.44: bytes=32 time=305ms TTL=255
Reply from 192.168.100.44: bytes=32 time=292ms TTL=255
Reply from 192.168.100.44: bytes=32 time=18ms TTL=255
Reply from 192.168.100.44: bytes=32 time=1ms TTL=255
Reply from 192.168.100.44: bytes=32 time=2ms TTL=255
Reply from 192.168.100.44: bytes=32 time=44ms TTL=255
Reply from 192.168.100.44: bytes=32 time=50ms TTL=255
Reply from 192.168.100.44: bytes=32 time=57ms TTL=255
Reply from 192.168.100.44: bytes=32 time=60ms TTL=255
Reply from 192.168.100.44: bytes=32 time=67ms TTL=255
Reply from 192.168.100.44: bytes=32 time=74ms TTL=255
Reply from 192.168.100.44: bytes=32 time=1ms TTL=255
Reply from 192.168.100.44: bytes=32 time=1ms TTL=255
Reply from 192.168.100.44: bytes=32 time=107ms TTL=255
Reply from 192.168.100.44: bytes=32 time=24ms TTL=255
Reply from 192.168.100.44: bytes=32 time=32ms TTL=255

Both devices are within three metres of the access point, both are associated on the same 5HGz channel.

Any ideas why this is happening? Will I see such poor performance with other network protocols? I am hoping to implement a UDP project where latency needs to be reasonably consistent and reasonably low (e.g. between 1 and 30ms)

2

I have managed to answer my own question. The variable latency is down to the fact the WiFi mode defaults to “power saving”.
By including <wificonf.h> I was then able to call wifi_disable_powersave(); and after that I see more accceptable ping times and jitter:
Reply from 192.168.100.44: bytes=32 time=4ms TTL=255
Reply from 192.168.100.44: bytes=32 time=8ms TTL=255
Reply from 192.168.100.44: bytes=32 time=3ms TTL=255
Reply from 192.168.100.44: bytes=32 time=2ms TTL=255
Reply from 192.168.100.44: bytes=32 time=3ms TTL=255
Reply from 192.168.100.44: bytes=32 time=2ms TTL=255
Reply from 192.168.100.44: bytes=32 time=2ms TTL=255
Reply from 192.168.100.44: bytes=32 time=5ms TTL=255
Reply from 192.168.100.44: bytes=32 time=2ms TTL=255
Reply from 192.168.100.44: bytes=32 time=2ms TTL=255
Reply from 192.168.100.44: bytes=32 time=2ms TTL=255
Reply from 192.168.100.44: bytes=32 time=2ms TTL=255
Reply from 192.168.100.44: bytes=32 time=2ms TTL=255
Reply from 192.168.100.44: bytes=32 time=2ms TTL=255
Reply from 192.168.100.44: bytes=32 time=2ms TTL=255
Reply from 192.168.100.44: bytes=32 time=2ms TTL=255
Reply from 192.168.100.44: bytes=32 time=3ms TTL=255
Reply from 192.168.100.44: bytes=32 time=17ms TTL=255
Reply from 192.168.100.44: bytes=32 time=2ms TTL=255
Reply from 192.168.100.44: bytes=32 time=2ms TTL=255

The logic here is that with power saving, the outgoing pings are being stored in the wireless access point, with the ‘data avaialble’ flag set in the next beacon, which stimulates the device to call down the data.
With power saving off, the device has its receiver running the whole time (with some power penalty), so the AP knows it can send out the ping as soon as it receives it.

2 Likes