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.
I tried this, and it did not fix my issue with Moonlight (streaming desktop video)
I’ve verified that the wifi card that came with the 11th gen intel laptop does not have this issue. It’s just the MT7922 that came with the AMD laptop I have now