Re: [Cake] small cake_hash optimization?

[Sebastian Moeller <moeller0@gmx.de>]

Hi Pete,

[NITPICK]
please note that "cake 950mbit " will only assume 14 bytes overhead which does not reflect what is really happening on ethernet

Gb Ethernet:
7 Byte Preamble + 1 Byte start of frame delimiter (SFD) + 12 Byte inter frame gap (IFG) + 4 Byte Frame Check Sequence (FCS) + 6 (dest MAC) + 6 (src MAC) + 2 (ethertype)
7 + 1 + 12 + 4 + 6 + 6 + 2 = 38 bytes

so the actual consumed bandwidth for MTU 1500 packets will be:

950 * ((1538)/(1514)) = 965.06 Mbps

so below a MTU of (14 * (1000/950) - 38) / (1 - (1000/950)) = 442 Byte the cake shaper will not avoid filling the ethernet NIC's queues (which might not be a bid issue with BQL).


I guess my point is when shaping ethernet be sure to add "overhead 64 mpu 84" to your cake invocation to actually account for the link layer properties.
[/NITPICK]

Best Regards


> On Nov 22, 2017, at 13:37, Pete Heist <peteheist@gmail.com> wrote:
> 
> 
>> On Nov 22, 2017, at 11:06 AM, Pete Heist <peteheist@gmail.com> wrote:
>> 
>> I’ve not done any testing on what the real impact of this change would be, or even if it breaks something.
> 
> Ok, at least a little crude testing with sar:
> 
> https://docs.google.com/spreadsheets/d/1LKoq5NaswuHm9H1atXoZA1AhNDg6L4UYS3Pn5lCsb1I/edit#gid=0
> 
> ~10% less cake CPU at GigE in this case? What’s a better tool for timing kernel module functions?
> 
> Would really need to test if host fairness still works, otherwise this is irrelevant…
> 
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake