I have a 300/300 mbps connection. Speed test results on average report 220-250 mpbs over WiFi.
I decided to try SQM and used all the default settings. I set packet overhead to 44. When I run a speed test with SQM enabled, my result over WiFi drops to 70-90mbps.
I have the download and upload speed set to 95% of 300 mbps, so 291,840 kbps.
Is this normal for SQM to reduce bandwidth by that much?
I have my fiber connection set at 98% of advertised speed for ingress and egress, cake and piece.of.cake for Queue, and Link Layer Adaption turned off.
I get no bufferbloat, and 94% of advertised speed on speed tests (Ookla Desktop app).
what about wired? If both wired and wifi suffer the same speed loss, perhaps either your settings are misconfigured, or your router simply can't handle what you're trying to make it do - adding info like, what router you're using, and even what version of OpenWRT may help answer you
I’m running 21.02 on Linksys MR8300. It has a quad-core CPU with 512 mb RAM.
Well, the router should handle it - though having quad cores doesn't mean they're being used to their full potential
Anyway, if you're comfortable using ssh - install htop and monitor the CPU usage during the speed test (you could also install luci-app-ttyd instead of using ssh - never used it, so not sure how good it is)
Have you tested wired performance?
Wired, SQM enabled - 141.82 down, 247.94 up
SQM disabled - 299.75 down, 340.50 up
Let me test with htop - thanks for that.
It's very hard to give advice without knowing your (router-)hardware. SQM is quite CPU intensive and doing traffic shaping at 300 MBit/s (what else, PPPoE?, VPN?, etc.) is very demanding, most routers typically used with OpenWrt would fail miserably under these conditions (aside from mvebu, RPi4, x86_64, maybe sunxi and rockchip).
OP did respond when I asked what hardware he's using
[I missed that, thanks]
MR8300 means ipq4019, it can do roundabout 360 MBit/s without SQM - with SQM being (mostly) single-threaded, 300/300 MBit/s are too much for this hardware.
Wouldn't irqbalance help here?
I do have irqbalance enabled but the majority of interrupts appear to be isolated to cpu0.
I'm not following you here. Where did you see that ipq4019 can only handle max 360Mpbs? My primary WIFI network is on the 5ghz Qualcomm Atheros IPQ4019 802.11nac, which can support up to 867Mbps. It was on this network that I ran the wireless speed tests and I see a drop from appx 250Mbps with SQM off, vs 70-90 Mbps with SQM on.
I also have a WPA2 network enabled on the the 2.4ghz Qualcomm Atheros IPQ4019 802.11bgn which supports up to 400Mbps and I only use this for my laptop that can't connect to a WPA3 network, so I use this for WPA2 only.
Couple of notes, when using htop, it's good to go into the display settings (F2?) and enable the more detailed info in the bargraphs. This makes SIRQ (in purple) show up well, and that's usually where your CPU hits the wall, vs raw CPU usage.
Second, since you are on 21.02.0, there is a new feature available, Packet Steering, in Luci. Network - Interfaces - Global network options. This helps a lot on my x86, RPi4 users also report it helpful. Cake will always be on one core, but this can spread the rest of the networking load around and keep one from maxing out sooner. Try it out, either instead of or with irqbalance.
Practical testing on a faster line, WAN-to-LAN routing/ NAT/ firewall, no software flow-offloading.
can you drop ur setting for sqm
and how did you turn off Link Layer Adaption
I could not get this to work recently.
From the Qualcomm website on the IPQ4019
Wi-Fi Peak Speed: Up to 1.733 Gbps
What is peak speed?
Let's start with what it is not:
It is not wan to lan with NAT and firewalling. It is not more than 10' in distance. It is not one 1GB port to any or all others.
What is it? it a perfect situation in the local network that 4 717MHz CPUs can handle until the heat throttles them down.
The radio capabilities are not a factor for your question: "Why does SQM bring my 4 717MHz CPUs to a crawl?"
This explains why.
But, specifically, this does the numbers for you.
Evidently in an ideal world, we should have maybe 1.2GHz processors or better, and maybe have two cores at least one can handle interrupts on the receive interface, and one can handle interrupts on the send interface, and they can share the firewall and queueing duties.
It takes 2 of your 717MHz cores just to keep up with one set of those jobs.
Read the rest because I'm not going answer anything that @dlakelan took the time to cover.
@JonP has the best advice for you, which is
It does work well on my Pi4, so it is not just a report anymore: it works on the Pi4.
We are not to blame for your throughput. Challenging our explanations is not going to change physics.
Upgrade to the latest stable firmware, which is hopefully 23.05.2 for you and enable packet steering across all 4 cores.