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 <[email protected]> wrote: > > >> On Nov 22, 2017, at 11:06 AM, Pete Heist <[email protected]> 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 > [email protected] > https://lists.bufferbloat.net/listinfo/cake _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
