Don't do that install htop (as that will show information for all CPUs) and look at the %idle of all CPUs, if one CPU get close to 90-1--% load your SQM is likely CPU bound. Some CPU cycles like SIRQ/softirq are not accounted to individual processes, so you only need to look at the overall data per CPU.
Here is the problem, on a dual CPU router like yours, 48% idle might mean one CPU essentially fully busy at 100% while the other only has a 4% load -> 100-(100+4)/2 = 48% idle
But it could also mean both CPUs only half loaded at 52% 100-(52+52)/2 = 48% idle
The seconds is benign, the first is bad as any process on the 100% loaded CPU is saturated. SQM's qdiscs are not really multithreaded* and can essentially only run on one CPU at a time.
*) IIRC the real problem is that they ue a common lock, but the effect is the same
Exactly this, you will see one core at 90+% and the other perhaps around 20%-30%.
There is no magic bullet, but x86_64, RPi4 and r4s can deal with these speeds (and sqm) easily - and the r7800 can stil serve as managed switch and AP. During (local) testing, my c1037u was totally bored while doing sqm at 1 GBit/s (symmetric) line speed - it didn't even have to clock up - extrapolating, I'd venture that even this ~10 year old x86_64 CPU would easily do 2.5 GBit/s.
root@OpenWrt:~# opkg update
Downloading https://downloads.openwrt.org/releases/21.02.3/targets/ipq806x/generic/packages/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_core
Downloading https://downloads.openwrt.org/releases/21.02.3/targets/ipq806x/generic/packages/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/releases/21.02.3/packages/arm_cortex-a15_neon-vfpv4/base/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_base
Downloading https://downloads.openwrt.org/releases/21.02.3/packages/arm_cortex-a15_neon-vfpv4/base/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/releases/21.02.3/packages/arm_cortex-a15_neon-vfpv4/luci/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_luci
Downloading https://downloads.openwrt.org/releases/21.02.3/packages/arm_cortex-a15_neon-vfpv4/luci/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/releases/21.02.3/packages/arm_cortex-a15_neon-vfpv4/packages/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_packages
Downloading https://downloads.openwrt.org/releases/21.02.3/packages/arm_cortex-a15_neon-vfpv4/packages/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/releases/21.02.3/packages/arm_cortex-a15_neon-vfpv4/routing/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_routing
Downloading https://downloads.openwrt.org/releases/21.02.3/packages/arm_cortex-a15_neon-vfpv4/routing/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/releases/21.02.3/packages/arm_cortex-a15_neon-vfpv4/telephony/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_telephony
Downloading https://downloads.openwrt.org/releases/21.02.3/packages/arm_cortex-a15_neon-vfpv4/telephony/Packages.sig
Signature check passed.
root@OpenWrt:~# opkg search htop
root@OpenWrt:~#
root@OpenWrt:~# opkg install htop
Installing htop (3.2.0-1) to root...
Downloading https://downloads.openwrt.org/releases/21.02.3/packages/arm_cortex-a15_neon-vfpv4/packages/htop_3.2.0-1_arm_cortex-a15_neon-vfpv4.ipk
Installing terminfo (6.2-3) to root...
Downloading https://downloads.openwrt.org/releases/21.02.3/packages/arm_cortex-a15_neon-vfpv4/base/terminfo_6.2-3_arm_cortex-a15_neon-vfpv4.ipk
Installing libncurses6 (6.2-3) to root...
Downloading https://downloads.openwrt.org/releases/21.02.3/packages/arm_cortex-a15_neon-vfpv4/base/libncurses6_6.2-3_arm_cortex-a15_neon-vfpv4.ipk
Configuring terminfo.
Configuring libncurses6.
Configuring htop.
root@OpenWrt:~#
Non of those, from your neighbourg country. I spent enough time doing business in yours and enjoyed Boom Festival so many times that Portuguese became a very familiar language.
Due to the type of connection you have, I think you should start thinking on following the route of separate devices for routing and providing WiFi access. It's confirmed to be the best way lately, unless you can get an RT3200 or similar. Otherwise, what has been recommended regarding capping your connection or shaping only upload bandwidth is your only solution for now.
Not fully, they use an ONT and fiber optics, but whether the network is an active AON network (with the ONT mainly being a media-converter between ethernet over fiber and copper) or a passive PON (with the ONT converting between say GPON and copper ethernet) is not explicitly clear.
However, many/most ISPs in Europe and other places seem to have converged on PON, so in all likelihood that is a GPON network. If you can figure out the model and maker of your ONT we might be able to figure out details (which have little influence on your home network, at best it would be nice to know.)
One more thing. At least in my case, setting option download '0' makes the stop command of sqm to return the errors I mentioned above. Is this a bug or is expected?
we really try to make sure to remove any leftovers, so might want to simply silence these error outputs. Just relaying on download rate being zero is a bit tricky, since we have no fully reliable state so that zero could have been edited after sqm was started with download >0.
Well, after running a few tests, with some different speeds, and changing NOECN to ECN in uplink, I see that ECN kinda put a bit more load on the cpu.
I started with 150000Kbps, then 120000Kbps, then 100000Kbps and finally put it the same as the uplink at 950000Kbps. I see always very close to 100% load on one of the cpus (#1) no matter the speed limit.
So, I can also assume that the speed limit plays no role in the load on the cpu!
From 120000Kbps down to 95000Kbps I always got A+ for the bufferbloat score! Gonna keep it like this for like a week, to see if the IPTV problem improves or not!
And also, I'm not sure I can assume that having 200Kbps (which was the limit when I set the speed in sqm to 4950000Kbps) or 495000Kbps or 95000Kbps, the load will always be the same, around 100%.
Am I correct?
Only for HTB+fq_codel (so simple.qos, simplest.qos and simplest_TBF.qos) cake ignores the ECN settings and always allows ECN. But note ECN required that the endpoints mark ECN eligible packets with either ECT(0) or ETC(1), dor NotECT packets ECN/NOECN will make little difference (but if you are already CPU-limited you might notice the small additional cost for checking the ECN bits).
No, try 25/25 Mbps for a change, the CPU load should drop...
Only if you are CPU bound otherwise there should be a correlation of CPU load with throughput.
heheh, this is going so wrong to me right now! xD
I thought I was doing something legit and you just break me down with 3 words... Cake ignore ECN.
I didn't understand this. Could you please rephrase? I have no knowledge on NotECT.
Will try..
Once more, I'm not sure of the meaning (non native english here) of CPU bound!
Edited;
Of course you're absolutely right! I started testing at 25000Kbps, increasing then several steps untill I see the CPU load near to 100%, which was at around 75000Kbps up / down. So, I think I'll leave it like this for the rest of the week.