Would it work on any router like AX53U? I have an AX59U right now.
So here is some tests I did. The best result so far was disabling all offloading and enabling SQM to 950mbits, but it still got 500mbps at most. It lowers the speed by a lot, I've tried to download stuff from internet, indeed it's 500mbps:
Just noticed on your screenshot over on HTOP - Zapret?
That's kind of a regional thing to bypass DPI - so that can impact your performance perhaps...
I will try without it sometime but I don't think it affects that much.
53U can not even forward gigabit without offloads, even less with QoS.
59U while significantly faster still may need to reduce bandwidth if CPU grows full under traffic.
Do you need SQM with a 1Gbs connection? SQM will only make an effect when there is congestion on the line, how often is your connection congested?
For modern routers with powerful processors, this is a useless thing, especially if the router has gigabit ports and you receive the same gigabit from the provider with a gigabit switch.
This may be useful if under the same conditions you receive a lower tariff, for example 500 or 250 megabits. Your provider squeezes your channel with its shaper and here it already depends on how correctly it does it. If correctly, then you do not need to do anything, and if crookedly and awry, then this can help you a lot and, as a rule, the setting consists only in setting 1 Gbit for input and 1 Gbit for output, no matter how paradoxical it may seem and the manuals say otherwise.
Rarely, I now tested without SQM and hardware offloading, I still get like +3-4 ms or something. But full force speed tho. I am thinking maybe sqm is useless for hardware offloading?
Kind of totally impossible to account traffic bypassing cpu and returning counters once a minute only to nftables. Only thing considered in offloads is DSCP class (3 bits) , it is similar to pfifo_fast from the birds eye.
SQM causes only an additional load on the router
at a speed 1000 you can connect a multi-storey building
I struggled with delays, ping, but it didn't help me in any way.
sqm only made it worse.
I have a problem on the provider's side.
His ancient equipment doesn't hold traction.
For AX59U Filogic 830, just barely. You'll have a hard time reaching gigabit if you run anything else on it.
The AX53U is a MT7621 SoC. This CPU cannot route more than around half Gig without hardware offloading, and it will not support more than 100-200 Mbps SQM throughput.
SQM will not work with hardware offloading. The bad news is you must use hardware offloading to route Gigabit on this router. The good news is that if you are getting only +3 to +4 ms additional latency without SQM, then you really don't need SQM. It might help with rare latency spikes, but if your average latency is only increasing 3 to 4 ms under a Gigabit load, it's doubtful you are experiencing enough of those to notice.
I suggest you stick with hardware offloading, stop worrying about SQM and be happy.
If your claim is that SQM can not work on a 1 Gbps WAN link, connected to a 1 Gbps LAN link, then you are in for a pleasant surprise, SQM can and does help even in that situation...
SQM consists out of 3 components:
a) a traffic scheduler, mostly stochastic flow queueuing (fq_codel, cake, fq_pie)
b) a per queue active queue management components (AQM)
c) a traffic shaper
The traffic shaper is only needed in some configurations, when we di not control the actual bottleneck link's transmission side. So for a true 1 Gbps WAN we might not need a traffic shaper for the upload direction, e.g. if the wan interface implements BQL to create the required back-pressure for the AQMs to operate on.
But for the receive/download side, the problem typically is that some where on the ISP side a fast ingress link >> 1 Gbps (in our example) feeds a number of links connecting to the customer's routers, and there traffic might arrive faster than 1 Gbps for a given customer and will grow a queue... Now if the ISP manages these queues well, than SQM might not be required but that is as true at 1 Gbps as it would be at 1 Mbps, and ISP's (while improving a bit over the last years) generally do not manage their queues as well as possible. (It still is up to each network admin to decide whether SQM offers enough to be worth it, but the point is it still can improve the responsiveness under load).
SQM typically will not even see/operate on packets that get diverted via a hardware offload fast-path, so typically SQM is incompatible (baring SQM like implementations inside the offload engines, like the fq_codel variant for Qualcomn's NSS system).
Assuming that is right, you should disable it on your router. However I consider it likely that you might simply have incorrect expectations in this case what SQM can/will deliver.
Well, typically SQM should not make things worse, but I agree that there is only a finite set of conditions it can help with, and these depend on the root cause of the observed issues.
Or, you accept the steep sacrifice of potential throughput and run with SQM configured for the 100-200 Mbps it can deliver on your router (maybe even downgrade to a cheaper internet plan). Both IMHO valid options, as so often: "your network; your rules; your decisions".
What I mean is that if your provider has everything set up correctly before your router, then there is no point in using this function.
If your router is simply the "last mile", it cannot harm your traffic so much that it needs to be fixed.
In my limited experience that is unfortunately the exception, not the rule. Many ISPs apparently optimize their access networks for the capacity-test (often misnomed as spedtest) usecase, that is throughput over latency under load /responsiveness.
If you are the lucky customer of a clued and competent ISP (maybe one using LibreQoS), then you might truely not benefit from running your own SQM instances. Unless you are interested in its secondary features like sharing available capacity equitably between active machines. Your network, your rules, so if you are happy without SQM, by all means do not use it. I would recommend to actually test that though, so you do not need to bet on the competence of your ISP... but then, I am not neutral in this matter, so I would say that, wouldn't I?
There are so many "competent providers" that after fiddling around with the settings all day long, getting an A+ in the test, by the evening we have such a mess that we have to turn it off, or reconfigure it again until the morning))). You are very lucky that if you set it up once and it works for you for years.
Well, the relevant toggles would be mostly the shaper rates, so if your ISP's network suffers from wildly changing congestion over the course of a day, maybe consider running cake-autorate to have the shaper limits adjust adaptivly? Or set the shaper limits to work well during primetime/evening and simply accept a loss in potential throughput during the rest of the day. Or do not run SQM at all if all of this does not help or is inacceptable, as I said before "your network, your rules".
That's the whole point.
It's not a cure for everything. Everyone's network is different. It's worth a try if you want, and if it turns out you don't need it, then you don't need it.
No, it is not, but what it cures "over-sized and under-managed buffers/queues" is still rather the norm and not the exception judging from what I read here in the forums, when helping folks. So I partly agree, if your ISP has well-managed queues and the desired "fairness" between entities SQM offers only little, but do yourself a favour and do not simply assume your ISP to do the right thing regarding responsiveness under load. The issue is that most people will use capacity tests to check whether the ISP delivers the contracted rates, and typically larger queues give consistent high throughput, so ISPs are incentivised to configure large buffers.
True, however some things are universal, e.g. queues...
Exactly, it turns out we agree
this has been an interesting discussion.
I think the situation of having 1Gbit symettric connection with a fast-enough router is not uncommmon now. then the real-world bottleneck gets moved to the client side, especially with wireless connections.
what do the experts here suggest for this common situation? should SQM be optimized for a typical slower wireless client, so as to not clog up both airtime and queues while waiting for the slow clients?
Over a medium to long range Reyee RG E5 dumb Access Point using 80 MHz wide WiFi on channel 149 (txpower set to 28 dBm)... Gateway is a NanoPi R5C on 24.10.1 (24.10 compiles rockchip with CONFIG_PREEMPT_NONE_BUILD=y
, so the R5C can comfortably handle half Gig CAKE running 24.10) with a DOCSIS 3.0 cable modem (so, no PIE) and 500/20 ISP service.
With gateway running CAKE:
https://www.waveform.com/tools/bufferbloat?test-id=d8326f76-23f6-4f6d-bc95-bdbb2dc565e2
Without gateway running CAKE:
https://www.waveform.com/tools/bufferbloat?test-id=60bec01f-af65-4036-8db6-1f10cf7e4f77
Not a lot of difference on the download, where I assume WiFi is the limiting factor, but upload without CAKE is more spiky over WiFi. Real technical term there - spiky