Access point is an Asus RT-AX88U, 802.11ax using 5Ghz.
rtt min/avg/max/mdev = 1.626/14.116/21.042/5.346 ms
Most pings to the AP appear to be in the 15ms range.
I would blame the AP except the Intel AX210-based system 50cm away from my Framework gets
Minimum = 1ms, Maximum = 9ms, Average = 1ms
Interestingly the AX210 system gets 4ms in Linux. I wonder whether it’s a measurement difference.
Could be a bug needing to be reported. You could compare it against the AX210 if you have one available to test against. I have not had any issues per se with the MT7922.
AMD with MT7922 here too.
mtr gives me more consistent results.
Also, I see ~ 15ms to the access point (with mtr), but www.google.com can be 1-2 ms less. Probably something about the stack/firewall on the access point/router.
Can you try disabling power saving in NetworkManager if you’re using it?
I’m running Fedora GNOME so using NM. By default:
$ nmcli c s '<SSID>' |grep power
802-11-wireless.powersave: 0 (default)
and based on wavemon output this defaults to power saving on.
In this state, mtr <access point> shows an average of 11-12 ms, but mtr www.google.com is almost the same, at 12-13 ms.
After disabling power save:
$ nmcli c mod '<SSID>' 802-11-wireless.powersave 2
and toggling WiFi from the GNOME quick settings to let the new setting take effect, wavemon shows power-save off.
With this setting, mtr <access point> is indeed lower now, 1-2 ms, but mtr www.google.com is still the same as before.
It looks like to me (and I remember seeing this in some other report about this apparent jitter/latency with MT adapters) that power saving doesn’t actually have as much real performance hit as a pure ICMP-based test like ping/mtr might suggest.
All my speed tests (I like https://speed.cloudflare.com/) show no issues with jitter or unexpectedly high latency. Upstream latency/bufferbloat improved as expected after I added QoS/queue management on the AP/router. Throughput saturates the ISP’s expected speeds (400Mbps down, 100Mbps up). The 5GHz channel I use has no other APs/signals as far as I can tell from scans.
Forgot I posted this, found it while Googling as I definitely hit this issue again!
64 bytes from 10.0.0.1: icmp_seq=23 ttl=64 time=152 ms
64 bytes from 10.0.0.1: icmp_seq=24 ttl=64 time=218 ms
64 bytes from 10.0.0.1: icmp_seq=25 ttl=64 time=98.9 ms
64 bytes from 10.0.0.1: icmp_seq=26 ttl=64 time=6.10 ms
64 bytes from 10.0.0.1: icmp_seq=27 ttl=64 time=47.5 ms
64 bytes from 10.0.0.1: icmp_seq=28 ttl=64 time=35.3 ms
64 bytes from 10.0.0.1: icmp_seq=29 ttl=64 time=36.8 ms
64 bytes from 10.0.0.1: icmp_seq=30 ttl=64 time=26.5 ms
64 bytes from 10.0.0.1: icmp_seq=31 ttl=64 time=6.29 ms
64 bytes from 10.0.0.1: icmp_seq=32 ttl=64 time=1.88 ms
64 bytes from 10.0.0.1: icmp_seq=33 ttl=64 time=2.13 ms
64 bytes from 10.0.0.1: icmp_seq=34 ttl=64 time=121 ms
64 bytes from 10.0.0.1: icmp_seq=35 ttl=64 time=10.7 ms
64 bytes from 10.0.0.1: icmp_seq=36 ttl=64 time=42.2 ms
64 bytes from 10.0.0.1: icmp_seq=37 ttl=64 time=66.0 ms
64 bytes from 10.0.0.1: icmp_seq=38 ttl=64 time=3.76 ms
64 bytes from 10.0.0.1: icmp_seq=39 ttl=64 time=13.2 ms
64 bytes from 10.0.0.1: icmp_seq=40 ttl=64 time=145 ms
64 bytes from 10.0.0.1: icmp_seq=41 ttl=64 time=3.01 ms
64 bytes from 10.0.0.1: icmp_seq=42 ttl=64 time=5.89 ms
64 bytes from 10.0.0.1: icmp_seq=43 ttl=64 time=111 ms
64 bytes from 10.0.0.1: icmp_seq=44 ttl=64 time=38.4 ms
64 bytes from 10.0.0.1: icmp_seq=45 ttl=64 time=49.0 ms
I think at this stage I’ll replace the card with something else - it’s not just ping or measurement latency, it’s noticeable when SSHing into the laptop.
5ghz AX network, Fedora kernel 6.8.11-300.fc40.x86_64
I’ve seen references to ICMP being treated by the stack/driver as “eh, we’ll get it there when we get it there” wrt waking the adapter up from sleep. So ping/mtr numbers may be overstating latency/jitter for “real” UDP or TCP traffic.
This is not just ICMP - it’s noticeable with an SSH session - there’s delay on keystrokes.