Open jaber-the-great opened 1 year ago
We did try that at one point. The problem is that using "rate" for HTBs (nodes) in that way results in the burst never being used for any leafs of that HTB. That becomes a tremendous hassle to troubleshoot. For HTBs, we set Ceil as the upper limit, and set Rate very close to the Ceil amount (98%, but it could be 100% too I think) so that every deeply nested node still has some chance of providing bandwidth up to or near its Ceil rate. Doing it this way allows HTB to handle cases where there is some small level of over-subscription or over-provisioning at some choke-point along the hierarchy (applicable to 99% of modern networks). Adding a rate/ceil for the nodes/network.json would lead to major network issues for anyone who tries to use it that way.
Thank you for explanation. I had this intuition when I was reading CAKE and LibreQoS source code: CAKE uses rate based limiter instead of token bucket. LibreQoS uses hierarchical token bucket instead of a rate based limiter. Therefore, to make the HTB work like a token bucket, we set the rate and ceil of HTB equal for each queue. When the burst size and rate are equal, it works as a rate based limiter (here). However, for each node in the subtree of HTB, we can set the min and max bandwidth as LibreQoS.py does it in here
Hi, When defining network in custom mode (not using UISP/Splynx), we can only set the max upload download rate. Then, when creating shaped devices in line , we consider 98% of max upload/download as the min upload/download. The min bandwidth determines the rate of the HTB and the max bandwidth determines the ceiling(burst size) 1) I think it would be good idea if we can specify it directly when creating custom network. Currently I first create the network and then edit the ShapedDevices.csv Since I need this feature, I can go ahead and implement it and add it as a feature to LibreQoS 2) Is there any specific reason for choosing 98%? Shouldn't we allow larger burst size?