4ms Ping to Openwrt AP

Hi, can someone explain why do i get 4ms ping to my Openwrt SQM AP?
Screenshot_52

my interfaces:

Well, there is one reading of 1ms.

What do you get with SQM off?

the same with SQM off

I see. I get mostly 1ms on my Archer C7.

You may want to be specific about the device you have (and the number of connected clients) in care someone knows about that particular device.

You don't have to worry about obsecurimg private IPs. They mean nothing to anybody who isn't inside your network.

using the raspberry pi 3 model b connected to the router on a DMZ enabled port, 3 clients via wi-fi (i get the 4ms ping on wi-fi but it should usually be 1ms), yeah i know

testing the wifi on my router gives me 1ms

Could you explain the topology a bit better?
The raspberry is the one running openwrt and has the wifi access point?
The router is a different device? Does it have an access point too?

yes, the raspberry pi is the one with openwrt and has the wifi access point, its connected to the router via lan on a DMZ enabled port (to prevent double NAT)

the router access point is off but i just turned on to test the ping to the router gateway and it shows 1ms
if i connect to the openwrt AP (router AP off) i get 4ms ping to luci IP (openwrt gateway)

this is just weird
Screenshot_54
it keeps fluctuating from 1ms to 120ms, sometimes stays on stable 4ms for a while

here's a 1 more reading

How many clients are connected to the access point? Are they downloading something or are they idle?
Can you verify that cpu utilization in the raspberry is not high?

i am the only client with no download active (still same 4ms results) , cpu usage via htop

CPU usage never goes past the 5% even with a download active

Just to be certain, could you uninstall SQM, reboot and try one more time?

i get the 4ms with SQM off though (confirmed off via system log), would uninstalling make a difference ?

Maybe some leftover settings are still active. Hence the removal and reboot. Your setttings file is preserved, so you can reinstall it later and keep your old settings.

i think the ICMP ping packet is not really that important to Openwrt so that's why its getting low priority 4ms delay

What you're seeing is normal ping for a wifi network with low latency. Wifi does (no surprise) introduce latency and the fluctuations you're seeing is most likely the link speed changing which is according to spec and to save power. That's the very short version :wink:

I'm seeing 3ms between my desktop and laptop on a WRT3200ACM (mwlwifi) running trunk/master for example.

actually is not. this is how the ping over wifi should look like

2.4G, connected to archer c7:


PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.606 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.581 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.644 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=1.25 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.558 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=0.579 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=0.640 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=0.557 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=0.585 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=0.560 ms
64 bytes from 192.168.1.1: icmp_seq=11 ttl=64 time=0.562 ms
64 bytes from 192.168.1.1: icmp_seq=12 ttl=64 time=0.790 ms
64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=0.555 ms
64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=0.565 ms

5Ghz, connected to LBE-5ac:

PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=1.38 ms
64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=0.771 ms
64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=0.768 ms
64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=0.759 ms
64 bytes from 192.168.2.1: icmp_seq=5 ttl=64 time=1.02 ms
64 bytes from 192.168.2.1: icmp_seq=6 ttl=64 time=0.800 ms
64 bytes from 192.168.2.1: icmp_seq=7 ttl=64 time=0.766 ms
64 bytes from 192.168.2.1: icmp_seq=8 ttl=64 time=0.978 ms
64 bytes from 192.168.2.1: icmp_seq=9 ttl=64 time=0.778 ms
64 bytes from 192.168.2.1: icmp_seq=10 ttl=64 time=0.764 ms
64 bytes from 192.168.2.1: icmp_seq=11 ttl=64 time=0.764 ms
64 bytes from 192.168.2.1: icmp_seq=12 ttl=64 time=0.761 ms
64 bytes from 192.168.2.1: icmp_seq=13 ttl=64 time=0.759 ms
64 bytes from 192.168.2.1: icmp_seq=14 ttl=64 time=1.19 ms

1 Like

This sometimes happens if a client uses wi-fi power saving. Unfortunately, I don't have Windows instructions how to disable it.

i just checked and i do have my wi-fi adapter power saving mode set at "Maximum Performance" so i don't think thats the problem

The ICMP isn't exactly high priority and due to some WiFi power saving mechanisms the results aren't always very accurate.

Use something like flood ping to get more accurate values:
sudo ping -f 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
--- 192.168.1.1 ping statistics ---
11533 packets transmitted, 11532 received, 0.00867077% packet loss, time 446ms
rtt min/avg/max/mdev = 0.493/0.660/8.587/0.204 ms, ipg/ewma 0.731/0.661 ms

Normal ping will result into something like this:
64 bytes from 192.168.1.1: icmp_seq=39 ttl=64 time=1.77 ms
64 bytes from 192.168.1.1: icmp_seq=40 ttl=64 time=1.45 ms
64 bytes from 192.168.1.1: icmp_seq=41 ttl=64 time=1.47 ms
64 bytes from 192.168.1.1: icmp_seq=42 ttl=64 time=1.46 ms
64 bytes from 192.168.1.1: icmp_seq=43 ttl=64 time=1.48 ms
64 bytes from 192.168.1.1: icmp_seq=44 ttl=64 time=1.55 ms
64 bytes from 192.168.1.1: icmp_seq=45 ttl=64 time=0.939 ms
64 bytes from 192.168.1.1: icmp_seq=46 ttl=64 time=1.28 ms
64 bytes from 192.168.1.1: icmp_seq=47 ttl=64 time=1.45 ms
64 bytes from 192.168.1.1: icmp_seq=48 ttl=64 time=1.35 ms

I am sure there is also an alternative for windows.