I paid good money for this router in my country.
I feel so scammed...
Don't be, it is not a bad device per se, but it is also not a device with a noticeably powerful CPU either, as long as this was not sold as heavy duty router things should be OK.
And to put things into perspective currently many routers come with arm a53 or a55 CPUs which are also not that new (the a53 is also 10 years old) and not that powerful either, your raspberry4 with its a72 cores still is a pretty decent and competent router.
Hmmm.....
This post doesn't seem to account for need of AQM/SQM on APs, why is that?
Since I did not write that (@dlakelan wrote that helpful post) I can only speculate... I believe this is because these are typically two independent problems, with doing it on the WAN link being the easier part. Foe WiFi the real solution is not really to set up SQM with fixed shaper rates for all WiFi traffic, but to move the AQM and scheduler into the WiFi AP itself, which is exactly the route that OpenWrt went.... (but this admittedly leaves the internet upload via WiFi problem unfixed).
Scheduler meaning?
fq_codel/cake are combinations of flow-schedulers and AQMs, that is they separate packets based on which application flow they belong to and schedule traffic from all flows equitably, so that no flow gets starved (both will also gently help new flows a bit to that equilibrium between flows is achieved a bit earlier). For each flow these will use one active queue management instance, that is driven by the sojourn time that is for how long a packet was in the queue.
Reading online AQL is a form of AQM?
AQL is airtime queue limit, this is more like WiFi's equivalent of ethernet's byte queue limits (BQL), both help in making sure the driver/hardware queues are only as large as they need to be and adapt to the actual traffic patterns... in a sense both AQL and BQL do indeed actively manage a queue, but I would still not consider these to be proper AQMs, but that is a nomenclature problem... but both have in common that on a router they will likely not be enough to keep responsiveness under load high.
Here is a link that describes the parts sitting a top of AQL pretty well:
https://www.usenix.org/conference/atc17/technical-sessions/presentation/hoilan-jorgesen
Got it,
I am really really sorry but a lot of that she over my head,
Do you want the router to be SQM? AQL? SQM with no shaping?
I am quite new to this
So as a rule of thumb, sqm works pretty well on fixed rate links. On variable rate links the best we came up with are IMHO the different autorate projects like cake-autorate and lua sqm-autorate and perl sqm-autorate. That however requires active RTT or better one way delay (OWD) measurements, that are relatively easy to perform against servers in the internet. In theory this would also work for WiFi but you would need to run an independent controller per station, and IMHO that is not a realistic option.
So ATM the pragmatic way forward IMHO is to pick an AP that implement airtime fairness as well as trying to connect all truly latency sensitive devices via ethernet cables directly to the router...
But I understand, that is not always possible and so compromises need to be made, or rather local policy needs to be set, and I think each network admin needs to find the best policy for their own network.
This is balderdash. With hardware NAT, yes, the MT7621 is Gigabit capable. Without hardware NAT and without QoS and using the CPU for all its worth, the MT7621 is doing well to "bulldoze" its way through little more than half a Gig.
I know this, because I've actually used MT7621 hardware as my gateway router. But you don't have to take just may word for it. Ask Wil Knoll how his ER-X performs, or do a Google search.
2 Likes
With SQM? Or without?
Without SQM. SQM and hardware offload are not compatible. SQM relies on the CPU to process packets, but offload bypasses the CPU, so the two don't get along together.
Like moeller0 said, this doesn't mean the MT7621 is bad option. It can actually be a very good economical option. But it does have CPU limitations, and SQM needs a lot of CPU. I could get around ~100 to 150 Mbps CAKE (depending on Openwrt version) and ~200 Mbps fq_codel/simple SQM throughput on my ER-X gateway router.
1 Like
Thanks, so this is around twice of my estimate, based on my old single core MIPS 24K... as I said the actual core design of these MIPS SoCs for cheap routers has not changed much in the last decade...
Right, I am assuming stock vendor firmware done usually urilize AQL, airtime fairness, etc?
Sound about right. The dual core / four thread MT7621 helps fq_codel out compared to a single core MIPS, since fq_codel can make use of multiple threads. No help for CAKE though.
1 Like
It's not a bad assumption that stock firmware is using all the tricks it can, but I wouldn't know.
I find it weird that some people can achieve ~450 with sqm
Ref link in my original post
I bet the stock firmware still uses a kernel version from well before these things were invented....
But it can not any more than cake... at best you can separate out the ingress and egress shaper instances on different CPUs... that said cake is noticeably heavier in its CPU hunger...
For fq_codel it helps a bit that you can reduce the cost of the shaper by going from HTB to TBF... while cake's own traffic shaper probably is more costly than even HTB.