Hi!
I upgraded my internet connection to 400/40 Mbit/s. (Docsis 3.0)
Modem syncs with 450560000 bps / 41984000 bps
Sqm is configured to ~ 95% of those values.
427000/39000
Speedtest shows around 350-365 MBit/s.
Without sqm i get ~ 430 MBit/s (-1518/1448 = ~ 450 MBit/s close to the syncrate)
Upping the download rate in sqm upto 450 Mbit/s makes no difference in download speed.
Always around ~350 Mbit/s.
Setting sqm download rate way higher then 450 MBit/s, like 500 MBit/s, does make a difference in download speed.
CPU usage is around 30%/80% (Dual Core)
I also have a different question about overhead (again :|)
I know, i already had a long discussion on the cake mailing, why overhead 18 is correct for docsis but
my modem shows this:
Maximum Concatenated Burst: 1522 bytes
Why did they choose 1522 bytes here and not 1518 bytes?
What device are you using. What is idle percentage during speed test. I'm quite sure you are CPU limited, there have been about a hundred posts like yours over the last year. To handle those speeds with SQM requires maybe top of line ARM device but most likely an x86. You can probably do just the uplink but downlink speeds require some serious cycles.
I have the feeling that something else is going here.
Is it possible that the cmts somehow is throttling the download rate (or amount of channels used?)when it notices that the client is not able to archive the full download speed?
The most important question to determine if CPU is the issue is what is the idle percentage during speed test. After we establish whether a single core is saturated or not, then we can move on.
CPU is a 1,3 Ghz arm dual core.
CPU usage during the speed test 30% on one core and 80% on the other core.
irqbalance doesn't work on this device cause the irq driver doesn't allow remapping of the irq affinities.
Ok, so that means one of your cores is saturated. I'm pretty sure cake is only operating on one core, so although your CPU has more cycles on the other core, they aren't accessible to you for SQM purposes, I suspect.
It's plausible that irqbalance would help if you could make it work. Maybe someone else knows more about that @anomeome seems to have some ideas?
In the end, I've been saying that people should move to x86 for anything over 200Mbit for a while, SQM is in my opinion an essential feature for a router, and it requires some considerable horsepower at high speeds, more than even ARM can handle.
I have dropped SQM since an update to a docsis 3.1 modem, but on a rango I was using SQM with irqbalance in the past. A little more horsepower there though.
You might also test with fq_codel based simple.qos instead of cake. I noticed a few weeks ago that cake consumed quite a lot of CPU in ipq806x based R7800.
If you do this please try upstream sqm-scripts, we changed how we calculate the HTB burst-buffer and quantum to save a few CPU cycles at higher bandwidths (but since we did not enough have meaningful testing yet, this is not yet in the openwrt packages). So if anybody tests this and notices robustly higher bandwidth utilization with the new code, please open an issue at https://github.com/tohojo/sqm-scripts to report this (and in case this does not help, please also report ;))
But please note you will not get all the goodies that cake offers.
I note that this still could mean one core fully pegged or any combination. But here is another thing, even if top only reports 50% utilisation for a single core rputer, cake might still choke as top reports in a granularity >= 1 second, and if the core is at 0% for 500ms and at 100% for the other 500ms top will veridically report 50% and yet sqm will be severely under-shaping...
So i tried to overlock the cpu by 300Mhz to 1600Mhz.
Cake download limit is set to 420000 kbit/s.
Speedtest shows ~ 300 MBit/s
CPU Idle is around ~ 60% now.
When i disable cake:
Speedtest shows: ~430 MBit/s
CPU Idle around: ~85%
Setting Cake to 500000 kbit/s (way to high)
Speedtest shows: ~385 MBit/s
CPU Idle around ~ 40%
Could you post the output of "tc -s qdisc" for the cake(420000) and the cake(500000) case? I want to see if/how the quantum variable changes in relation to the set speed. Like HTB/TBF' burst buffer these can help cake to keep the real interface fed during CPU shortages (but at the cost of more induced latency, so this needs to be seen as a trade-off).
Have you manually installed the most recent upstream version of sqm-scripts, before this test? If not please try... And have a look at /usr/lib/sqm/defaults.sh, you will find variables that let you influence the buffer sizing by the duration required to empty that buffer at the configured bandwidth, it would be quite interesting to see whether increasing the buffer duration might give you back the apparently lost bandwidth.
BTW, it is not the leaf qdisc component of cake or fq_codel but either cake's inbuild shaper component (for layer_cake/piece_of_cake) or HTB/TBF in simple/simplest that actually drags in the high computational demands...
Is it possibly that the CMTS can detect if a device can't reach full speed and then throttles down the download? Like some kind of threshold? If threshold(s) > increase the usage of download channels?
This only works with HTB. Cake is much better at autoscaling things, but if the new buffer-sizing code in sqm-scripts solves the problem for simple.qos then it might be possible to make this also configurable in cake (and even though this will come at the cost of more latency so will never be the preferred solution).