[Cake] Loving the progress on Cake (tins) - tc?

Sebastian Moeller moeller0 at gmx.de
Thu Oct 15 03:55:45 EDT 2015


Hi Jonathan,

On Oct 15, 2015, at 06:42 , Jonathan Morton <chromatix99 at gmail.com> wrote:

> 
>> On 14 Oct, 2015, at 14:11, Kevin Darbyshire-Bryant <kevin at darbyshire-bryant.me.uk> wrote:
>> 
>> Is there a matching update to user space 'tc' yet and I've just missed
>> it?   I can see there's been quite a change to the stats structures &
>> output so I definitely understand its not a trivial change to 'tc' so
>> maybe requires more bake time.
> 
> Toke’s repo has now been updated accordingly.  It still understands the old format as well as the new one.  However, it *does not* read the interim format, because it cannot be distinguished reliably from the old format, and the two are mutually incompatible.

	I guess that is fine, as cake is not upstreamed we can just go and break backward compatibility. Is there a way to detect that though to inform the user that they need to upgrade tc and sch_cake to get it working again? (I have not tested that, so there might be a warning already...)

> 
> The new stats struct can be extended with new statistics when required.  The old one could be extended with a larger number of classes/tins, but that proved to be less useful.  Although I had left a generous amount of padding originally, all that space was eventually used up.
> 
> Also put in now are keywords for the RTT parameter:
> 
> 	datacentre = 100 us
> 	lan = 1 ms (covers both ethernet and home wifi)
> 	metro = 10 ms
> 	regional = 30 ms
> 	internet = 100 ms (default)
> 	oceanic = 300 ms
> 	satellite = 1 second
> 	interplanetary = 1 hour

	This I like, quite a lot! I do wonder though why you keep the target clamped at 5ms? Especially for the last two that seems not too helpful. Also would you accept a change to also allow manual setting of the target (mainly to allow people to do some research, the great thing about your cake design is that it does the “right things” per default, but it would be great if it also allowed crazy things if people ask nicely ;) ).

	One more question, I noticed that the symbolic overhead names work quite unexpectedly in that basically the last one specified wins, except if the last one is via-ethernet, ether-fcs or ether-vlan. We do not document or enforce the ordering of these keyword in any way, so this sure will confuse people. My proposal would be to make all additive (well via-ethernet stays subtractive) so any combination will just evaluate to the sum of the individual components (I would also include raw and conservative into the additive list, all in the spirit of having a simple to explain rationale: all overheads are additive and the symbolic names really are just constants; note I would then also include the components, like pppoe pppoe llc snap vcmix individually (though I ned to check wether these are real constants)). I am volunteering to do these changes if nobody objects that is.

Best Regards
	Sebastian

> 
> - Jonathan Morton
> 
> _______________________________________________
> Cake mailing list
> Cake at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake




More information about the Cake mailing list