Update 05/28/2024:
Created a script to allow one to easily update the aql_txq_limit:
Update 05/14/2024:
@tohojo Provides a great explanation of these settings here:
Original Thread:
This thread is intended to be a GL.iNet GL-MT6000 specific continuation of the
E8450/RT3200 thread I kicked off here, some time ago.
I'm kicking off this topic specifically for discussion around AQL and other wireless latency points. This is not meant to be another topic for discussing SQM on the ethernet side of the device.
Having been inspired by this, myself, I wonder if I might entice anyone to join with me in experimenting a little. I interested to see if anyone is willing to run the following and do some testing along with me.
Recommended Testing/Bechmark Tool:
Crusader Network Tester
Latest releases available here:
AQL Settings
For 2.4ghz radio:
22.03.x+: for ac in 0 1 2 3; do echo $ac 2500 2500 > /sys/kernel/debug/ieee80211/phy0/aql_txq_limit; done
For 5ghz radio:
22.03.x+: for ac in 0 1 2 3; do echo $ac 2500 2500 > /sys/kernel/debug/ieee80211/phy1/aql_txq_limit; done
You can confirm the settings applied by checking the following:
For 22.03.x+: cat /sys/kernel/debug/ieee80211/phy*/aql_txq_limit
It should look something like this:
root@AP:~# cat /sys/kernel/debug/ieee80211/phy*/aql_txq_limit
AC AQL limit low AQL limit high
VO 2500 2500
VI 2500 2500
BE 2500 2500
BK 2500 2500
AC AQL limit low AQL limit high
VO 2500 2500
VI 2500 2500
BE 2500 2500
BK 2500 2500
To retain the settings upon restarts, you can consider adding something like the following to your /etc/rc.local file on your device(s):
...
# AQL Tweaks
aql_txq_limit=2500
for ac in 0 1 2 3; do echo $ac $aql_txq_limit $aql_txq_limit > /sys/kernel/debug/ieee80211/phy0/aql_txq_limit; done
for ac in 0 1 2 3; do echo $ac $aql_txq_limit $aql_txq_limit > /sys/kernel/debug/ieee80211/phy1/aql_txq_limit; done
...
If you do test, some before and after buffer bloat results would be most interesting. Thanks!
I'm hopeful @dtaht will be interested in joining in here, as well. 
Soapbox moment... it's generally believed that "fast" WiFi means "high bandwidth". Every wireless device maker proves this by advertising fancy model names with BIG numbers (e.g. AX3200 or AX11000) that people will think are impressive. Yet, how many of them publish latency reduction (AQL, BQL, Airtime Fairness, etc.) figures?
The majority of consumers don't realize that the "fast" they feel is more a product of lower latency than higher bandwidth. That's my ultimate hope of this thread, and the numerous other threads like this one. Just want to help people FEEL the difference for themselves and start demanding better of manufacturers.
