From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id CA9933CB41 for ; Sun, 22 Apr 2018 17:31:53 -0400 (EDT) Date: Sun, 22 Apr 2018 23:31:51 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1524432712; bh=ZSEwJX1o1nBV3gq9nPh3zX2m5S0OnDS59tECaxMFPow=; h=Date:In-Reply-To:References:Subject:To:CC:From:From; b=cSiDRBYFoEtN8VfwhRa5MSnDkVwYoaY7BCA3qrhAcgSMxEBAcUGn4BB024U6/uOWd WHfDDWr5nnqCk4t7ceNVfCmYtplY1UIABNy6KlmFgeIDPJr+QUC4dWMeh04i1zXAF7 p2aVOTVva/6uiXBDTj782VEA3aFF5DFxqqGX31sS79ly8DDIXEKJcaO1p1AQixguVa BuXfuChDOOKR4bvEacjJvQlZCtkp5lOsGTeANXczfSqywT9Uu5CQ0PEDItKFEYqQGc g9WqYZ7cm7uKVsD70D4w+g+aKK6tV6PgUbZoKWvkrcs+ziZyoLpImL1NvBBoFRkeSS kujZpWyGOU30A== In-Reply-To: References: <87a7tv3r5z.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: Jonathan Morton CC: cake@lists.bufferbloat.net From: =?ISO-8859-1?Q?Toke_H=F8iland-J=F8rgensen?= X-Clacks-Overhead: GNU Terry Pratchett Message-ID: Subject: Re: [Cake] Testing variants of the MTU latency scaling X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2018 21:31:54 -0000 On 22 April 2018 23:09:54 CEST, Jonathan Morton = wrote: >> Takeaways (see attached plots): >>=20 >> - The MTU scaling does indeed give a nice benefit in egress mode >> "tcp-download-totals" plot=2E From just over 6 Mbps to just over 8 >Mbps >> of goodput on the 10 Mbit link=2E There is not a large difference >> between 2MTU and 4MTU, except that 4MTU hurts inter-flow latency >> somewhat=2E >>=20 >> - The effect for upload flows (where Cake is before the bottleneck; >> 10mbit-upload=2Epng) is negligible=2E >>=20 >> - The MTU scaling really hurts TCP RTT (intra-flow latency; >> tcp-upload-tcprtt-10mbit=2Epng and rrul-tcprtt=2Epng)=2E >>=20 >> - For bidirectional traffic the combined effect is also negligible=2E >>=20 >>=20 >> 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=2E I'll >> merge Kevin's patch to do this unless someone complains loudly :) >>=20 >> If you want me to run other tests, let me know=2E > >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=2E 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=2E Ah, that was a typo=2E I meant that it should only be active in *ingress* = mode=2E=20 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 clien= t and the bottleneck)=2E -Toke