This is because Location Services are on. Just realised it a few moments ago thanks to a link were it mentions it that @ka2107 shared with me. In my machines they are always off as I use them to play from time to time in GeForce NOW.
Once things are this good, it is helpful to zoom out to see bigger spikes. The all, rather than all_scaled, graph does this. Also, could you post the .flent.gz files for future reference? I do hope with some stuff waiting in the wings, we can improve this still further.
I am disturbed by how much location services interrupts flows, and wonder how many users leave it on, not knowing it's causing them other trouble. What is the actual width of the pulse? It looks to me to be nearly 2 seconds.... the irtt plot we are using for starlink can help here.
Sorry if this is unrelated, but I just noticed that for an AP connected to my main RT3200 router on OpenWrt 22.03-SNAPSHOT r19541-ec9f82fa18 via 5Ghz over WDS, if I connect to AP over 2.4Ghz the ssh speed is very slow (as in I type and it takes a while for characters to appear) on idle WiFi load, whereas it becomes very reactive when I run a speed test.
hard to say. If you have applied nbd's latest patch to deal with multicast, I'd first suggest you turn off your wifi interface power save on the device and the AP if they are on. If that doesn't help then idk, maybe.
I have a bunch of smart plugs that send out multicast packets on 2.4.
In any case when connecting to AP over 2.4, then ssh from laptop to main router is periodically painfully slow, but internet speeds seem normal. When connected to AP over 5, then ssh from laptop to main router is normal.
Give it some time to see if the symptom comes back (maybe as much as few days). Others have observed (before the latest fixes) that the latency symptoms can take time develop or come back after turning off AQL. Regardless, ping @nbd with some details on the AP (device, what's it running, does it have the latest multicast fix patch, etc.)
What explains why I can see internet speeds like 15Mbit/s, but then ssh speed to main router painfully slow. Is that because the ssh connection is being given too low priority or something?
Seems non-related. We share a very similar scenario, 2 WDS clients connecting to a main WDS AP. In my case connecting to my 2.4 GHz network doesn't affect ssh latency at all.
I have a slightly wacky arrangement in that I have main router provide guest WiFi WDS AP on 2.4 and normal WiFi WDS AP on 5.
Both APs connect to both WDS APs on main router and provide 2.4 AP for guest WiFi and both 2.4 and 5 APs for normal WiFi.
Connecting to normal WiFi on 2.4 on AP seems to give problem (at least in presence of Netflix related traffic on guest WiFi and multicast from about ten smart plugs also on guest WiFi).
The ssh is painfully slow like entering 'logread' takes ages to respond. As you can see from screenshot above iperf3 shows normal rates but lags behind on SSH.
One acts as main router and the other two connect to main router on separate WDS APs for guest WiFi (WDS AP on 2.4Ghz) and normal WiFi (WDS AP on 5Ghz). They extend guest WiFi on 2.4Ghz and normal WiFi on 2.4 and 5Ghz.
I have a single SSID for guest WiFi and a single SSID for normal WiFi and FT is enabled for both across the three devices.
All works fine to provide WiFi throughout large three floor home, but somewhere along the line in terms of snapshot upgrades I noticed very slow ssh until I would reconnect my laptop to the normal WiFi and now I realise that it is because my laptop is connected over normal WiFi via 2.4Ghz and for some reason this exhibits significant delay / poor latency despite decent looking overall transfer rates. Reconnecting means switching over to 5Ghz and problem is then gone.
Only if that's the default behaviour. I haven't changed the default and don't bother with any of the DSCP marking stuff as I'm a little dubious about it all, at least for my particulars. Isn't life too short for endless tinkering around with DSCP markings?
For my 4G internet connection default CAKE with the autorate stuff works a treat.