Tests were run from a Linux laptop when nobody else was using the network after midnight, on a clear 5 GHz channel, on an idling system, with the access point in the same room, 70/70 signal, clear line of sight and no obstructions. Not that it mattered, I get basically the same results independent of the time of day, location, operating system or channel with this access point.
What I'm trying to find out by posting is, am I fussing over nothing? Should I just accept that shit happens (interference, other traffic, etc) a few percentage points of the time and move on? Or, should I start looking for a new access point?
Here's a thread you might find interesting: AQL and the ath10k is *lovely*
Read @richb-hanover-priv's post to help you understand the before & after graphs in the first post.
Put simply, it looks like OpenWrt 20.xx will have improved WiFi performance from the ath10k and ath10k-ct drivers. It's a result of the Make WiFi Fast project, which was done by some of the same people who worked on the SQM stuff (cake/FQ-CoDel) to reduce bufferbloat.
Also, this mailing list conversation shows that one of the OpenWrt developers very recently got his hands on a router with WiFi 6 (802.11ax) and 10 GbE, and has just started looking into it to see if he can get OpenWrt running on it. That's a very expensive router ($450 MSRP), but work on that could maybe help with developing for other (less expensive) routers further down the road.
@wterlave89 Did you reply to the wrong thread by mistake?
While I did read the referenced thread earlier and found it interesting, it's not very relevant to the issue at hand. Queuing makes a difference when loading the link. My tests were done at idle and the latency variation is nowhere as extreme as in the example. As such the most relevant factors are probably processing delay and interference, not queuing.
I'm not quite sure I subscribe to your trickle down theory of fancy expensive routers either
Regardless, it's not a given that newer and faster hardware reduces latency and jitter. If they do, then of course I'm interested in hearing more.
I was just mentioning those things because they're about future improvements to OpenWrt WiFi performance in general, over the next few years. I just thought people would find it interesting.
For the "trickle down" thing, I was specifically referring to how development for the Asus ax89x might help with other, future routers in the IPQ8074 family that have similar components, and through competition, prices should eventually go down on some of those models.
Thank you for this great report. If all reports on the forum included this much information, we'd be better off. Two more pieces of data would be relevant:
What kind of router, firmware, etc.
What kind of computer were you using (model, OS version, etc.)
PS These ping times don't surprise me. Thanks again.
What was the target of the ping test? Was it the Ap itself? Might be interesting to try the same test but pinging another device on same lan segment (so minimal or even zero cpu processing if via switch) - preferably connected via Ethernet.
These are my precursor tests before transitioning to Openwrt. Gotta have that data so that I know if I am better off or not
Wireless: TP-link RE305 latest stock firmware in access point mode
Computers: Dell Latitude E6510 with antiX 19.1. Measures replicated with approximately the same results on a Dell Vostro 5581 using the newest antiX 19.2, Ubuntu and Windows 10
Frequencies: 5 GHz channels 36 to 64
plugged in Ubuntu laptop connected to 1G switch port on VDSL2 modem
External references:
aforementioned Ubuntu laptop
colocated Edgerouter Pro on 1G fiber directly connected to core router
Results from all targets were correlated and corrected for processing and non-WiFi delays.
External references were used to determine stability and jitter of internal and external networks.
I believe a number of wifi devices will cyclically scan all channels to get a better immediate view of the wifi surround Ile doing so data transfer is temporarily stopped/delayed. At least I saw/see cyclically increasing RTTs in flent RRUL tests over wifi, that I do not see over wired connections. And the freqnency/period was too precise to be simply caused by RF noise. Not sure whether the OP has the same issue, but it might make sense to plot the RTTs simply over time and look for obvious cyvlic patterns....
Excellent observation! I already had the 5 GHz radio on a fixed channel, mainly because one of my devices does not do DFS channels, but the 2.4 GHz radio was set on Auto. I now disabled the 2.4 GHz radio completely to avoid any scanning activity and because none of my devices use it. Might as well not pollute the frequency for nothing.
I'll rerun my tests to see if this has any effect and watch for any cyclicals going forward. Might have to break out the Wifi sniffer if I see anything suspicious.
It's not the AP that does the scanning, it's the client. So your laptop/desktop will occasionally stop processing packets, and look for who else is available on other channels. Because it's changing channels, it can't be sending/receiving packets on the main channel. It does this to facilitate roaming for example. There's usually not much you can do about this as far as I know.
Turning off background scanning made my WiFi connection rock solid.
Mean deviation is 1.2 ms and there was one, count them one (1) packet that was over 10 ms over min rtt over a 1000 packet run.
