I still don't fully comprehend how DQL or the low-water mark helps reduce latency when we've already got AQL & ATF. I can see that the improvements, but I don't know how it works/it's mechanism with regards to the rest of the ath10k stack. Can anyone bring light to this?
Astute observation, and this is actually the reason I don't think spending more time on DQL for ath10k is the right thing to do. Making things airtime-based is clearly the right thing to do, so I'd rather spend the effort tweaking AQL. The main thing that is missing there (I think) is a global limit on the whole interface; AQL only has a per-station throttle. Ben's original patch (with the low-watermark tweak) was because he was running tests with a lot of stations (as in, hundreds), which has not been a case that has seen a lot of focus for AQL. So it ought to be possible to improve this case with the existing infrastructure...
I'd like openwrt to ship what we have so far. It's an enormous improvement and more users need it. We can keep sorting out better approaches as we have time.
I don't care about 100 users, I care about, oh, a max of 32. For openwrt.
Please consider >32 no longer unreasonable. Maybe not >32 high bandwidth users, but definitely >32 users.
These days vacuums, thermostats, smoke detectors, fridges, doorbells, TVs, chromecasts, speakers, game consoles, and cars in the driveway all want on wifi. Having a smart speaker that can control colour changing smart bulbs and smart plugs, all with their own wifi connections, are popular with kids these days.
Not to mention occasionally hosting big multi-family event like Christmas where the kids run off into little groups to have tiktok watching parties while others want to stream 4k netflix. Ideally openwrt can support all this. I'm more worried that 64 isn't enough than 32, at least in a non-covid-19 world.
If I have any one end goal with this work in making the ath10k sing and dance, its to finally be able to test the l4s vs sce concepts on real hardware, on wifi. I really lack time and braincells for hard core kernel development, I'm mostly just a theorist, and although I LOVE hacking on code, I have to spend too much time at layers 8 and 9 of the stack these days to focus on it. so if you know anyone that can lend a hand to this effort over here:
Perhaps we can make progress on adding similar features to the wifi implementation and analyzing them.
thx. There's a ton of other stuff worth doing in wifi as well... probably more important than this. I keep thinking importing an optional ack filter based on the cake ack-filter will help, and also I think the wifi implementation needs to also adopt the drop batching stuff that is already in the qdisc....
There have been a bunch of excellent, thorough benchmarks in this thread, but I haven't seen much in the way of real life usage results. Anyone want to share any impressions for real-life improvements with AQL for specific workloads (web browsing, gaming, video conferencing, whatever)? I realize that'd introduce a bit of subjectivity, but I'm curious.
My test deployment was in an area with a lot of 802.11ac wifi on the same base channel while I was running ht20, at a range of over 100meters. I got terrible throughput, and a lot of random - 2,2,2,2, then 100ms+ pings. Have no idea what was causing it to be that bad.
My guess is that I have to stop using the base 36 or 153 channels entirely for HT20. Which I'll do.
The other problem with my test deployment was that I really needed to rip out the mods I'd made to the 2ghz portion of the patch and do it right. But at least it's deployed now and upgrading software less of a problem.
So I changed my patch to use 10ms for the target for 2ghz and 5 for the ath10k. I am still pretty sure we have multiple problems, but I'm firing off a build now and will test in the morning.
I see also there is a beta for a newer ath10k-ct version?
I've been using the ath10k-ct 6/3 dated firmware since it dropped and it's been stable, at least. I had a 10ms target build a little while back and it seemed to give me a better balance between latency and throughput than the 5ms target.
Ah, FWIW, interestingly enough I'm running a 6/4 snapshot on my C7 AP, compared with 19.07.2 and then 4/3 snap, its been fairly stable as well. No special build or other adjustments, just got the snapshot on that day. Have had maybe one or two of the momentary 2.4ghz dropout events, maybe less than prior builds. Not setup for serious testing. DSLReports looks pretty good, when I can get the bufferbloat results. Also no VOIP, or much videoconferencing out of the home network at this point, so can't compare there. Multi use case of TV watching, some gaming, wife doing VPN and video conferencing, etc... no complaints so far. Will ask my wife if she notices any differences with her VC, compared to earlier. Since there weren't much issues before, not a great test...
Forgive me for being a little foggy on how it goes, can I expect commits to end up in the daily snapshots fairly quickly or same day, or is there some delay? Guess right now I'm at least partly up to date, (except for patch changes) with my C7 on the above 6/4 snapshot running kmod-mac80211 4.19.123+5.7-rc3-1-2? Or not?
If you're running kmod-mac80211 4.19 that would indicate that you're running a 4.19 kernel, which does not have AQL. Your kmod versions should start with 5.4.
For what it worth I just switched to the 5.4 kernel on my r7800 to try AQL and it's a huge improvement, really noticable with SSH sessions. Throughput is still fine too.