General Discussion about QOS/SQM

I also use docsisI also use docsis

mpu 64 is correct

In current sqm-scripts master it has been superceded by:

# set to zero to use htb default butst of one MTU

I was trying to find the post I was reading about this the other day where you and mindwolf was discussing usecs time for SHAPER_BURST_DUR_US and the kernel.

For reference here when it states setting "0" = one MTU. what does this string exactly translate in to ms ?
Also if it's 1ms by default does switching this to say SHAPER_BURST_DUR_US=500 translate in to 0.5ms ?

the US in SHAPER_BURST_DUR_US is the conventional way to write µs or microseconds if greek letters are not avalable.

Yes. But keep in mind that to achieve acceptable throughput the interface should not "fall dry" with 500 on a sufficiently fast link the qdisc will need to inject packets into the driver/interface twice per milliseconds, which can be a lot...

Thanks for clarification, so what happens when I set this to "0" how many ms does the switch "0" in µs
..if 0 = 1 MTU and I have 1500 or 9000 does this mean 1.5ms - 9ms / or is this simply 0µs Regardless,

My SHAPER_BURST_DUR_US=100 wondering if setting this to "0" will make much of a difference?

I think that in case of setting this to zero you will get a burst of 1749 bytes allowing for am ATM/AAL5 encapsulated packet... see get_burst() in https://github.com/tohojo/sqm-scripts/blob/master/src/functions.sh:

    # let's assume ATM/AAL5 to be the worst case encapsulation
    #	and 48 Bytes a reasonable worst case per packet overhead
    MIN_BURST=$(( ${MTU} + 48 ))	# add 48 bytes to MTU for the  ovehead
    MIN_BURST=$(( ${MIN_BURST} + 47 ))	# now do ceil(Min_BURST / 48) * 53 in shell integer arithmic
    MIN_BURST=$(( ${MIN_BURST} / 48 ))
    MIN_BURST=$(( ${MIN_BURST} * 53 ))	# for MTU 1489 to 1536 this will result in MIN_BURST = 1749 Bytes

    # htb/tbf expect burst to be specified in bytes, while bandwidth is in kbps
    BURST=$(( ((${SHAPER_BURST_US} * ${BANDWIDTH}) / 8000) ))

    if [ ${BURST} -lt ${MIN_BURST} ] ; then
	sqm_log "get_burst (by duration): the calculated burst/quantum size of ${BURST} bytes was below the minimum of ${MIN_BURST} bytes."
	BURST=${MIN_BURST}
    fi

However if the MTU is larger, so will the calculated MIN_BURST be.

No. Really the idea of this toggle is not to allow making it smaller than the default 1ms, but to allow for somewhat larger batches if a router gets close to its CPU cycles limit. By allowing larger batches that will make it less critical t get the CPU immediately... But if your router and link are both fast enough, reducing this is also an option....

so say having it already reduced from 1000 to 100 and having no issues would setting this to 0 be more help

a) this is only evaluated by scripts that use HTB, so simple.qos or simplest.qos
b) there is a sanity check to allow at least a full MTU packet that overrides too small settings, but this will only be visible if your log level is set to info, debug, or trace. If you do:

/etc/init.d/sqm stop ; /etc/init.d/sqm start ; logread | grep -e sqm

you should see a message if that happened though.

SQM: Stopping SQM on eth1
SQM: Starting SQM script: XXX.qos on eth1, in: 900000 Kbps, out: 900000 Kbps
SQM: XXX.qos was started on eth1 successfully
Wed Aug  3 11:24:22 2022 daemon.notice procd: /etc/rc.d/S50sqm: SQM: Starting SQM script: XXX.qos on eth1, in: 900000 Kbps, out: 900000 Kbps
Wed Aug  3 11:24:22 2022 daemon.notice procd: /etc/rc.d/S50sqm: SQM: XXX.qos was started on eth1 successfully
Wed Aug  3 11:24:22 2022 user.notice ucitrack: Setting up /etc/config/firewall reload dependency on /etc/config/sqm

ah I'm using cake.qos so I guess this would not imply then.

Exactly, cake does its own (sane) internal batching calculations and does not expose any way to control/change these.

But for sanity checking at 900000 Kbps, or 900 Mbps a single 1749 Byte burst will take:

1000 ms/s * (1749Byte * 8 bit/Byte) / (900000000 bit/s) = 0.016 ms 

So you would expect the info message only if you set SHAPER_BURST_DUR_US < 16...

Thank you for fuller explanation much appreciative. :beers:

Doing some testing with all of this forgot I should had subtracted 5% of my line for reserved trafficshapper
Been editing /usr/lib/sqm/ using slight modded cake.qos with ctinfo applied, both directions using egress.
I could try to make it better but as of now I'm a little impressed and tired, Stuff is kind of too much fun.

For science after adjusting reserved trafficshaper I switched BURST to 19µs even if it would not apply.

No errors in logs.

The get_burst() function will only be called in simple.qos and sim0lwst.qos, the two cake script simply, and silently ignore these settings. So I would expect no error messages.