300mbps SQM on MT7621DAT as dumb AP

Hello all, I am confused about the capabilities of the dual core, 880Mhz Mediatek MT7621DAT SoC on the TP Link Archer AX23, People have put carried results on the forum, some saying that the SoC can't handle anything above 150, But some can achieve 460 and even 700

I have a Raspberry Pi 4B which will handle all the other stuff like adguard, SQM to wan side, etc and function as wired router, the AX23 only has to be a dumb AP and do SQM over WLAN as wired bufferbloat tests give me a +0 whereas WLAN currently gives me anywhere from +30 to +150

So will having the RPI4 do everything else reduce the stress on the SOC and hell me achieve SQM on 300/350 line?

What are those numbers? Latency milliseconds or what? What are you trying to achieve and where are you now by means of (post a link):
Can you explain how internet traffic passes those devices in your home.

300/350 Mbps ISP GPON connection, using wired and SQM on, on my wired router, I get a A+ grade with about 0-2ms of bufferbloat which is very good, but on wifi that's upto 30-100ms depending on distance, 30being right next to it.

I have my ISP GPON ONU in bridge mode which connects to a raspberry Pi 4, 4 gb running SQM, which connects to a TP Link AX23 in AP mode.

Wifi and ethernet tests both connect to the AX23 which indicates wifi is bottlenecking.

I believe you actually need AQL only on the AP
see GL.iNet GL-MT6000 - AQL and WiFi Latency - Installing and Using OpenWrt / Network and Wireless Configuration - OpenWrt Forum


So AQL is only needed on WiFi SoCs that insist on handling large queues inside the driver/firmware, but I believe most/all modern WiFi SoCs do that...
According to:

the AX23 V1 with its All MT79xx radios should actually do so.
Alas, ATM there seems no way back from OpenWrt to vendor firmware so switching to OpenWrt is a one-way street, not everyone is willing to go there.

All AX23 revisions are identical btw.

Please produce links to test results, and /etc/config/wireless with passwords and mac addresses edited out.

Not on openwrt yet due to no revert procedure, I'll get you the results soon. I am out right now.

Obviously TP-Link can help you with their software.

I don't aim to fix this issue with tp link firmware, my concern is would my cpu be able to handle the SQM or AQL at those speeds on WLAN, since my rpi does wan sqm it should make it's life easier

My best bet is, yes for the internet download direction this will work reasonably well, fq_codel itself is not that CPU hungry typically it is the required traffic shaping that costs most CPU cycles and with AQL that is not required as AQL will create the required back pressure at a far lower CPU cost. But then it will not be totally free either, so you need to decide for your self. As we often say over here: your network, your rules :wink: (and if it breaks you can keep both pieces)


wifi by itself has rudimentary QoS known as WMM, otherwise known as diffserv4 hfsc, which comes at no CPU cost.

With qualiity uplink you do not need any additional SQM

openwrt defaults to egress fq_codel, which is very low resource, just that you need to verify it is applied to upstream egress path when turning your AP dumb,

Same likely sabotages OEM:
Your oem wlan latencies seem sub-par even for 10 years ago. Probably tp-link qos is applied in wrong place for dumb-ap setup and it is worth dusabling it.

1 Like

Mmmh, that is a generous description of WMM... but not factually incorrect.

I typically try to avoid telling people what they need or do not need, as I consider that to be a local policy decision that everybody needs to make for themselves...

But it does only help against bufferbloat if the egress link on which fq_codel runs is the actual bottleneck link and the bottleneck rate is the link rate, and the link can generate back pressure via BQL (ethernet) or AQL (WiFi).

No its is not. WMM is mandatory n WiFi if you want to go above ~54 Mbps... I also do not think that WMM is the right tree to bark up on here, but I reserve the right to be wrong on this assessment.

1 Like

The option is gone in AP mode, so it must be disabled.

1 Like

And how it compares to OEM NAT mode?
In principle OpenWRT can offload NAT to hardware, and mt76 platforms have open driver to do so. But your CPU is also powerful enough to bulldoze its way through 1000/1000 without any hardship.

Bufferbloat with my ax23 directly connected to the modem in router mode?

yep. the corner case also in OpenWRT - bridge alone is not offloaded to NAT offload engine.....

The dual core 880 MHz MIPS 1004KEc?

without QoS at 30-50% CPU usage....

Not sure I buy that, with saturating traffic on both radios and potentially firewalling... really MIPS* are over 10 year old designs suitable for below 100 Mbps agggregate internet capacity, but at best a stop-gap measure for a 300/300 link. The OP however already had the WAN side well under control using a RPI4B under OpenWrt and is looking for how to improve the WiFi/AP side of things since he connects all/most devices via WiFi. And there the vendor firmware already seems to fall short even in the presumably less demanding AP-only mode.

*) If you look closely at the 24k, 34k, 1004k lines you see little changes to the core design, sure they added multicore and SMT capabilities but at its core the design is over a decade old by now.