Questions about SQM settings

Don't do that :wink: 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.

@moeller0 @slh I just tried to install htop (I have it on my laptop) but in my router, it didn't find the package!

opkg update && opkg install htop, it is there.

root@OpenWrt:~# opkg update
Updated list of available packages in /var/opkg-lists/openwrt_core
Signature check passed.
Updated list of available packages in /var/opkg-lists/openwrt_base
Signature check passed.
Updated list of available packages in /var/opkg-lists/openwrt_luci
Signature check passed.
Updated list of available packages in /var/opkg-lists/openwrt_packages
Signature check passed.
Updated list of available packages in /var/opkg-lists/openwrt_routing
Signature check passed.
Updated list of available packages in /var/opkg-lists/openwrt_telephony
Signature check passed.
root@OpenWrt:~# opkg search htop
root@OpenWrt:~# opkg install htop
Installing htop (3.2.0-1) to root...
Installing terminfo (6.2-3) to root...
Installing libncurses6 (6.2-3) to root...
Configuring terminfo.
Configuring libncurses6.
Configuring htop.

LOL, something wrong, is not right! xD

opkg find htop

search does search <file|regexp> List package providing <file>

RTFM, mate. :wink: :slight_smile:

Update: smiley added.

Ok, don't need t get mad or be rude!

You didn't see my smiling face, man. Tudo estΓ‘ bem, you don't worry. :wink:

You're portuguese or brazillian. I'm portuguese. :slight_smile:

Ok, I installed it and in fact, one cpu gets overloaded. But, this could be mitigated if this sqm script could support multi-core, no?

In theory sure, but this is much easier said than done, so do not hold your breath while waiting for that to happen.

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. :wink:

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.

wtf? I was in Boom festival in 2001... ahahah

Ok, I think I'll make it 0 Mbps / 95 Mbps in my settings.
I just tried with

option qdisc 'fq_codel'
option script 'simplest.qos'

and eveything else the same, and I get better download results but only A for bufferbloat score!
I may go for the 0 Mbps / 95Mbps route!

@moeller0 did you check my ISP technology? You didn't said anything else about it! I hope it's giving me Fiber Optic signal as they say!

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.)

1 Like

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?

Probably a cosmetic issue...

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. :stuck_out_tongue:

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!

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.

I commented the 2 ECN options from the config.

config queue 'wan'                                                              
        option enabled '1'                                                      
        option interface 'eth0.12'                                              
        option download '75000'                                                 
        option upload '75000'                                                   
        option qdisc 'cake'                                                                                               
        option script 'piece_of_cake.qos'                                                                            
        option qdisc_advanced '1'                                               
        # option ingress_ecn 'ECN'                                              
        # option egress_ecn 'ECN'                                               
        option qdisc_really_really_advanced '0'                                 
        option itarget 'auto'                                                   
        option etarget 'auto'                                                   
        option linklayer 'ethernet'                                             
        option squash_dscp '1'                                                  
        option squash_ingress '1'                                               
        option overhead '44'                                                    
        option debug_logging '1'                                                
        option verbosity '5'                                                    
        # option iqdisc_opts 'nat dual-dsthost no-split-gso'                    
        # option eqdisc_opts 'nat dual-srchost'

It means that once you reach CPU limit it will be always close to 100% use, no matter what bandwidth you set.

If you reduce your bandwidth step by step, it will reach a point where you CPU use will drop, that is your CPU limit.

1 Like