GL.iNet GL-MT6000 - AQL and WiFi Latency

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. :slight_smile:


Update 05/14/2024:
@tohojo Provides a great explanation of these settings here:

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.

6 Likes

Inaugural Crusader post!

Crusader run to test my MT6000 AP from my 2021 MacBook Pro M1:

AQL (aql_txq_limit): 2500

1 Like

Hi. This looks like a test over an 80 MHz channel. What happens if you set up a 160 MHz channel?

Last time one of my friends tried this with a MacBook Pro (M2 Max 16 inch 32G / 1T) with his Mercusys MR90X, this was the result:

man I discovered the hard way that the MacBook Pro does not support 160 MHz over 5 ghz
I was getting absolutely terrible internet (not speed-wise), the voices in the video chat were breaking every now and then

You have a different AP and a different MacBook, that's why the question on whether they can form a viable 160 MHz setup.

Unfortunately I'm not going to be able to test this at this point. My M1 MacBook Pro only supports 80 Mhz channels:

From https://support.apple.com/en-tj/guide/deployment/dep268652e6c/web:

Wi-Fi specification details for MacBook Pro models

Wi-Fi specifications for the following MacBook Pro models are detailed in the table below.

  • MacBook Pro 16-inch, M2, 2023
  • MacBook Pro 14-inch, M2, 2023
802.11 standard, name, frequency Maximum PHY data rate Maximum channel bandwidth Maximum MCS index Maximum spatial streams / Type
ax@6 GHz 2400 Mbps 160 MHz 11 (HE) 2/MIMO
ax@5 GHz 1200 Mbps 80 MHz 11 (HE) 2/MIMO
ac@5 GHz 866 Mbps 80 MHz 9 (VHT) 2/MIMO
a/n@5 GHz 300 Mbps 40 MHz 15 (HT) 2/MIMO
ax@2.4 GHz 195 Mbps 20 MHz 9 (HE) 2/MIMO
b/g/n@2.4 GHz 144 Mbps 20 MHz 15 (HT) 2/MIMO

Wi-Fi specifications for the following MacBook Pro models are detailed in the table below.

  • MacBook Pro (13-inch, M2, 2022)
  • MacBook Pro (14-inch, 2021)
  • MacBook Pro (16-inch, 2021)
  • MacBook Pro (13-inch, M1, 2020)
802.11 standard, name, frequency Maximum PHY data rate Maximum channel bandwidth Maximum MCS index Maximum spatial streams / Type
ax@5 GHz 1200 Mbps 80 MHz 11 (HE) 2/MIMO
ac@5 GHz 866 Mbps 80 MHz 9 (VHT) 2/MIMO
a/n@5 GHz 300 Mbps 40 MHz 15 (HT) 2/MIMO
ax@2.4 GHz 195 Mbps 20 MHz 9 (HE) 2/MIMO
b/g/n@2.4 GHz 144 Mbps 20 MHz 15 (HT) 2/MIMO

I would love if someone with an M2 or higher Mac could give this test a try with the MT6000!

I was a dummy and forgot I do have another MacBook Pro that is an M2. So, given the horsepower inside the MT6000, I ran the crusader binary on one of my MT6000s itself. Otherwise my bandwidth to my main router would have been capped at my 1Gbps interfaces.

With that said, here are results from a 160 Mhz client (MacBook Pro M2):
5 sec load:

15 sec load:

2 Likes

Quick note: I note in the bi-directional test the macbook seems to hog most of the transmit opportunities, something I also see often with my macbook* on ath9K and ath10K APs...

(2015 macbook pro 15.7", 2023 macbook pro 16" M3, these are alas not my property)

1 Like

With my Powerspec 1530 laptop with an Intel AX201 160Mhz.
Before, with default aql of 5000/12000.

After, with 2500/2500.

Sure seems like an improvement. I'll (hopefully) run more, longer tests and get some flent results as well.

4 Likes

Fantastic! Thanks for sharing your results!

My results with a MB Air M1, in a position where signal is not the greatest. Today's OpenWRT snapshot.

Before (default):

After (2500/2500):

3 Likes

Thanks for the data! What is your user experience with the 2500/2500 setting? Your bandwidth is lower, but your latency dropped especially during the up/down simultaneous test.

Any noticeable difference in normal usage?

Tbh I can't say that it's especially noticeable, but that's because I didn't have real latency issues with the default values - video calls always worked fine, for example. I use SQM, though.

I ran an additional test with 1500 as a value. Looks like the sweet spot for this specific location:

4 Likes

I have a question, could any of you repeat this test with the GL.iNet GL-MT6000 stock firmware? Or is this based on recent enough OpenWrt to be essentially the same anyway?
(I do not own a GL.iNet GL-MT6000, so can not test this myself, but I would really like to see how OpenWrt stacks up compared to commercial offerings).

It's not, at all, the release firmware might have been closer, but they reverted to the all proprietary Mediatek SDK with old kernel, proprietary drivers and old butchered up OpenWrt roots.

3 Likes