On 22 April 2018 23:09:54 CEST, Jonathan Morton <chromati...@gmail.com> wrote: >> Takeaways (see attached plots): >> >> - The MTU scaling does indeed give a nice benefit in egress mode >> "tcp-download-totals" plot. From just over 6 Mbps to just over 8 >Mbps >> of goodput on the 10 Mbit link. There is not a large difference >> between 2MTU and 4MTU, except that 4MTU hurts inter-flow latency >> somewhat. >> >> - The effect for upload flows (where Cake is before the bottleneck; >> 10mbit-upload.png) is negligible. >> >> - The MTU scaling really hurts TCP RTT (intra-flow latency; >> tcp-upload-tcprtt-10mbit.png and rrul-tcprtt.png). >> >> - For bidirectional traffic the combined effect is also negligible. >> >> >> Based on all this, I propose we change the scaling mechanism so that >it >> is only active in egress mode, and change it from 4 MTUs to 2. I'll >> merge Kevin's patch to do this unless someone complains loudly :) >> >> If you want me to run other tests, let me know. > >I'm not actually sure what you've measured here - unless you've somehow >managed to swap "ingress" with "egress" mode in a strange manner. I >don't see any systematic measurement of the different MTU scales in >ingress mode in your results, which makes your assertion that it should >only be active in egress mode rather odd.
Ah, that was a typo. I meant that it should only be active in *ingress* mode. As for the results, as I wrote in my original email, all download flows go through cake in ingress mode (the device running cake is between the client and the bottleneck). -Toke _______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake