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):
[https://www.waveform.com/tools/bufferbloat]
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.
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.
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 (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.
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.
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.
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.
(and if it breaks you can keep both pieces)