Using HTB more efficiently with cburst and burst about libreqos

[dtaht]

Well, we tried it on a busy pre-wireless-n network... and it was awful. So making the idea available for further testing makes sense, but the default where htb autoscales these quantities should remain the default.

[rchac]

Hey Dave. Thank you for bringing this up and providing a possible solution. I will go ahead and test this in production as soon as I can. Thanks!

[rchac]

[rchac]

This is after the change. I forgot to run one before the change. But it appears to be working very well in terms of bloat.

[dtaht]

It looks like a modest win. (in the future, it helps to title the plots -t the_options_under_test) So could you change the code to
allow the BURST and CBURST variables to be set by in the config, defaulting to 3028, then set the classes to use those (instead of what I hard coded above) in the code and point users in the script at this github issue?

I don't know if that improvement in slow start (reducing the impact of it in the first few seconds) you are showing is to be believed or not, 10 runs, separated by a few seconds, aggregated together might be more revealing. If it's is real, my theory would be it allows for a more accurate tcp rtt estimate in the early phase of the test... and that we should begin considering bigger quantums in cake itself at higher rates.

The problem is that wifi has a limit on "number of packets" as well as "data", and it grows and shrinks relative to your mcs rate, (and a few other variables - see ongoing work at: https://forum.openwrt.org/t/reducing-multiplexing-latencies-still-further-in-wifi/133605/15 ) so at mcs-12 (on n) for example, you could fit in 8k or 20 packets. HTB only allows you to limit dequeuing from a bucket (essentially per customer with cake) by bytes, and then cake switches between flows based on the quantum (which is also in bytes). Anyway - for a base config - 3028 seems like a good compromise value - two big tcp packets, or a mix of a tcp and other packets, or a bunch of acks... it saves on cpu, it mimics real world tcp senders...

ac (and later) lets you send 4MB! and 96 (or more I forget) packets in a single burst. (I would in general prefer wifi just adopt fq_codel for wifi directly, per station queuing, atf, etc....)

[rchac]

Thank you for letting me know! Also sorry for delayed response - got COVID and was out of commission for a while.

[interduo]

man tc-htb shows:

       burst bytes
              Amount  of  bytes  that can be burst at ceil speed, in excess of
              the configured rate.  Should be at least as high as the  highest
              burst of all children.

       cburst bytes
              Amount  of bytes that can be burst at 'infinite' speed, in other
              words, as fast as the interface can transmit them.  For  perfect
              evening  out,  should  be  equal  to at most one average packet.
              Should be at least as high as the highest cburst  of  all  chil‐
              dren.

       quantum bytes
              Number  of  bytes  to serve from this class before the scheduler
              moves to the next class.  Default value is rate divided  by  the
              qdisc r2q parameter.  If specified, r2q is ignored.

I think it could be set globally not per ShapedDevices.csv row.
Tuning burst speed values is very important for small tariffs <20Mbits in aspects of website loading and some speedtests ;-)