I seem to be having a problem with SQM. If I enter any value other than zero for the download speed, my 180 Mbit/s cable connection gets cut to ~90 Mbit/s. Is this normal?
Currently I have my download set to 0 to disable ingress shaping, and my upload set to 100% of my average upload speed (5867 kbit/s). The reason I am not setting my upload to 85, 90, or 95% of true upload, is because it seems not to make a difference in terms of latency.
If SQM is disabled, I tend to get a 'B' for buffer-bloat at dslreports.com. If enabled, with my current settings, the letter grade improves to an 'A.'
Of course, I have tried multiple values for both download and upload, finding that 0 and 5867 kbit/s work the best. Perhaps one of my settings is off or could be tweaked further? I know when I played with these numbers in the past, (when I was using a different cable modem), I could reduce the latency, plus achieve higher than normal upload speeds.
As far as other settings go, I just followed the guide at...
You're going to lose some bandwidth any time you add one buffer to prevent another one from filling up. Basically what SQM does is put you in control of that buffer, not your ISP. So yeah, 10-25% loss in bandwidth is typical in my experience, depending on your ISP's equipment, settings, your line quality, and the phase of the moon.
Hmmm, that is surprising. I'd expect something around 140,000 - 200,000 kbit/s for a 180.000 Mbit/s line for downstream and similarly 80-110% of your upstream rate on your upstream.
Very likely that 90 Mbit is the limit of your CPU to shape packets. Set it to 170mbit and run a speed test while watching output of top look for percent idle during the download
My line quality is fine. I had somebody from Comcast inspect it and did a test earlier today. Yeah, a 50% cut seemed a little dramatic. lol, you were just joking about phases of the moon right?
170000 kbit/s for the down setting does nothing: no improvement in buffer-bloat, only a cut in speed. I didn't think about the CPU though. I bet your on to something, but I doubt it is the CPU itself. I have a AMD 1700x 16 threaded processor, but it could easily be an input setting I suppose. I'll play around with it some more tomorrow morning.
No that is not "normal", but it is also not that uncommon that at higher Bandwidth plans a router's CPU simple has issues doing the demanding traffic shaping work.
You could try the following:
log into your router via ssh and execute the following command: "top -d 1" (note to stop top you need ot press control-c)
The second row is especially interesting, especially the idle column (how much CPU cycles are "left over" once this approaches zero it is a sure sign, that your CPU runs out of steam, so to speak) and the sirq column (soft interupts, most of the heavy lifting of traffic shaping and wifi happens in sirq "context", so idle going very low and sirq going very hight typically indicates that the load exceeds the router's capabilities).
start a demanding speedtest, ideally a bidirectional test (maybe by starting two "normal" speedtests staggered in a way that the first is done with the downloadtest, when the second starts so one tests download overlaps with the other's upload).
2.a) monitor what is happening with the top -d 1 output...
A few questions, could you please post the output of the following commands:
cat /etc/config/sqm
tc -s qdisc #(before a speedtest)
tc -s qdisc #(after a speedtest)
cat /etc/os-release
cat /proc/cpuinfo
Note, as mentioned previously, my download was set to 0 to disable ingress shaping. It is now set to 179,617 kbit/s, (100% of average download), for purposes of this test. Upload remains at 5867 kbit/s, which is 100% of average upload.
Speedtest is set to auto-select servers based on latency, 16 download streams & 16 upload streams, Hi-Res buffer-bloat checked, upload duration 60 seconds, download duration 60 seconds, dodge compression is checked.
Output:
top -d 1...
Idle got to as low as 0%; sirq, never higher than 65%. These limits were tested during the download phase; the upload portion was much less demanding.
There you have it, you are running out of CPU cycles. Now that might not necessaily mean that your CPU is too wimpy, it would be sufficient, if the CPU either tries to powersave some or worse might hit thermal throttling... in both cases I would expect the CPU to run well below its nominal frequency...
But I have no hands on experience with that router/CPU, so maybe others with more direct knowledge might be better positioned to help.
Wow, go figure. One of the reasons I went with the Netgear R7800 was because it is more beefy than average. Thanks for your comments. I will see if there is anything I can do about this; if not, I'll just leave it at 0 to disable ingress shaping.
