MaxDownload rate

[jaber-the-great]

The LibreQoS.py does not allow MaxDownload rate less than 2Mbps (validateNetworkAndDevices function) but on the other hand, the sqmFixupRate function considers a case when MaxDownload is 1Mbps. 1) What is the reason the MaxDownload can not be less than 2Mbps ( Asking for our research testbed not ISP customer)? 2) case 1: return sqm + " rtt 300" in sqmFixupRate is redundant (unless we use MinDownload rate as the argument for the function not the maximum)

[jaber-the-great]

If it is valid, I can go ahead and submit the PR

[rchac]

1) MaxDownload is the "ceil" rate of the HTB. MinDownload is the "rate" of the HTB. Rate has to be less than the ceil, and we use integers for the Mbps variables. There are parts of LibreQoS.py where to determine the rate of a node, it has to subtract 1 from the MaxDownload. If MaxDownload is <2, that would lead to a situation where the HTB rate is 0 Mbps. 2) I thought CAKE used 100ms as its default? Could you help me better understand what you mean when you say redundant? Thanks!

[jaber-the-great]

1. I know that tc command uses integer values; libreqos.py uses Mbit. If I change that part to Kbit (for tc commands), I can have two different integer values for max and min download and the rate is still less than 1Mbit (eg minDownload 100Kbit and maxDownload 200Kbit). One question is that if I change the code for tc commands, would it cause some inconsistencies in the libreqos? For example some other checks or requirements in rust section of the code or inconsistencies with xdp?

2. Cake uses 100ms by default but it should use other RTT values for data rates less than 5Mbps. That's because FQ-Codel RFC says the the DRR queue scheduler should pass the traffic if there is less than 1MTU (here 1500bytes) of data in the queus: "The default target value is 5 ms, but this value should be tuned to be at least the transmission time of a single MTU-sized packet at the prevalent egress link speed (which, for example, is ~15 ms for 1 Mbps and MTU 1500). This prevents CoDel from being too aggressive at low bandwidths. It should otherwise be set to 5-10% of the configured interval" The comments in sqmFixupRate explain this issue (although not written very well)

[rchac]

1) Great point. It might break some part of the XDP side, but @thebracket could speak more to that. He's at a conference but will be back in a week or so.

2) Interesting. Neat. I'll defer to @dtaht on that one. We can certainly modify sqmFixupRate as needed. Thanks for catching that.

[dtaht]

I have not reviewed the code. Thank you for doing so. When we wrote cake we never imagined that anyone would use anything other than the integral shaper which automatically will scale the target value up at rates below 3 mbit. The workaround is to set the rtt value (in the 2mbit case, rtt 200, but the righter thing would be target 10ms interval 100ms in that case. Codel is very ineffective at higher interval values, and in the modern internet I have generally been using a value of 80ms or less. It is on my todo list to provide an override of this, but more to my hope, that sub 2mbit plans become a thing of the past.