On Mon, 23 Sep 2019 at 13:56, Jonathan Morton <chromati...@gmail.com> wrote: > > The overhead compensation matters more with small packets than with the > larger ones used for bulk transfers; for the latter, reserving a little more > bandwidth will appear to make everything work. For fibre I would try > "ethernet" and reserve about 1% bandwidth each way, then if possible test to > see whether there is any bloat.
The "ethernet" keyword is perfect for shaping real line rate ethernet, however it's more likely that the upstream ONU/OLT/BNG is shaping/policing without regard for the 8 byte preamble + 12 byte inter-frame gap. It's almost certainly blind to the native GEM framing of GPON. My starting point would be "mpu 64 overhead 18". There are possibly VLAN tags in use behind the scenes, so try incrementing overhead by 4 from there. For example, this is the simplified cake incantation for the upstream of my 100/40 GPON connection: tc qdisc replace dev eth2 root cake dual-srchost nat mpu 64 overhead 26 bandwidth 40Mbit There are 2 VLAN tags added by the OLT before my upstream traffic is policed by an aggregation switch, so 18 bytes ethernet (incl. FCS) + 4 bytes VLAN + 4 bytes VLAN = 26 Correspondingly in the downstream I use: tc qdisc replace dev ifb2 root cake ingress dual-dsthost nat mpu 64 overhead 26 bandwidth 99Mbit As alluded to by Jonathan, the 1% margin is required in order for cake to reliably enforce host/flow fairness on downstream/"ingress" traffic. So long as mpu/overhead/bandwidth are fine tuned, I haven't needed to allow for any margin in the upstream. -Ryan _______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake