Based on prior posts (most of which in this thread above) I got the impression support is needed in both the ath10k(-ct) driver/firmware and mac80211.
After a brief scan of the initial commit, most patches are to files in net/mac20811. There is only one line added to drivers/net/wireless/ath/ath10k/mac.c
which i think is the clue i needed to "disable AQL" for a test.
The firmware is a black box so I have no clue if it has/needs functionality to support AQL.
I have a few things to try and play with just not enough time to test do to "remote learning" starting up next week for my children. I may have to revert to something stable after that if this continues.
FWIW it looks like ath10k-ct 5.8 is comming (mailing list here) but if interpret @greearb's comment
If you are trying the 5.8 version, then it is almost completely untested and may be full of bugs.
then "master" may continue to be buggy for a while yet.
I think you are indeed correct about -ct firmware + driver being necessary to support AQL.
I switched back to the -ct firmware + driver on my build. But I did some testing I had not done before and it appears the -ct-htt variant of the firmware is the one causing me issues at the moment. When I switch away from the -ct-htt variant to just the -ct variant, my odd latency issues that I was experiencing before seem to go away. I had always been using the -ct-htt variant prior to now.
I'll run with the -ct variant for a couple days and see how things look, but thankfully you got me thinking on this again.
that's a great tip for me... I've always used the htt variant. I'll try the non htt and see if I get an improvement.
Based on what I've read, I think AQL should be functional with non ct driver/firmware (at least for the r7800), but I'm not the right person to confirm that.
EDIT: I just loaded the non htt variant and re-tested (like I have done above) and I still see the same undesirable (AQL) behaviour. irtt results seem little changed. I may have made some progress finding a non ct firmware to try but won't be able to test that for a bit. Regardless, I really appreciate the tip.
Yeah, something just doesn’t feel right with the -ct firmware right now. I take a substantial throughput hit over the standard ath10k, even with the non HTT variant. I’ll probably be switching back to my non-CT build in a little while.
Sorry this non-HTT route didn’t work out better for the both of us
So I built and loaded the ath10k driver commenting out the line wiphy_ext_feature_set(ar->hw->wiphy, NL80211_EXT_FEATURE_AQL);
in mac.c
Running with that, there are no aql files in /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0/stations/*/aql when stations are connected to phy0; however, cat /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0/stations/*/airtime
still returns an output.
Repeating the tests above "sans aql" gives similar results so it seems my testing/observations are more airtime fairness related than aql.
What makes a bigger difference is client/AP location (AQL enabled in the ath10k driver this case). Airtime fairness seems to behave more like I'd expect when all clients have a line of sight to the AP. i.e. the faster client stay fast while slower clients take a hit. Even then, I'm still surprised at how much of a bandwidth hit the slow clients take when I start simultaneous netperf sessions from 2-3 clients. It still seems like some clients come to a complete stop briefly. This may happen more frequently with increased router uptime - I'll need to test over an extended period.
As an aside, most testing I've done is with 80 MHz width channels on the 5 GHz band (channel 36). I tried with 40 MHz width and generally see similar behavior just not as pronounced.
Lastly, I'd really like to adjust the airtime station weights with a command like
r7500v2 # iw dev wlan0 station set <MAC address> airtime_weight 26
command failed: Not supported (-95)
but I only get the output above. Perhaps this hostapd commit will enable that (but I'm likely just misunderstanding).
There hasn't been much video conferencing going on in my household since the lastest mac80211 updates so I'll need to give this some time to see if it's really improved now or not. That and I'd still like to try a non-ct firmware just to see if makes a difference.
Thanks, I probably will. I assume doing so returns the airtime scheduler to what it was before (round robin) vs the new thing (virtual time-based).
It looks like there is a hostap-ct that has some form of "airtime config" option. I haven't looked into that yet - porting a package over to openwrt likely would take some effort.
in ath10k-5.4/mac.c, compiling, moving the resulting ath10k_core.ko
to /lib/modules/5.4.63/ath10k_core.ko and rebooting I still see an output from cat /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0/stations/*/airtime
and I can still reproduce the symptoms above.
I think I need to start a new thread specific to my device as this does not seem "AQL" related. Also I may have made some progress finding more up to date non-ct ath10k firmware to try (but I'll likely have to use the ath10k-ct driver).
I did rebase the patch fairly recently and sent it off to Felix for testing before posting on the list. He hasn't gotten back to me, but I assume it's on his backlog.
I do plan to do a bit more testing myself, but need to set up an environment for that (I'm awfully short on clients here). If you wanna volunteer for testing I can send you the patch, otherwise y'all will just have to wait
Generally, testing if fairness is worse/better than without the patch, and checking that it doesn't break anything (such as stations stalling entirely, that sort of thing)
