From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 490C721F7F6 for ; Fri, 6 Nov 2015 03:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1446807628; bh=NIAJrTnwELxk6T6JjHhOrgo25+3XOS0kkAVzrx1BHS4=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=IGTyCJf10WgkEi4BPlqNmu57bI0FvmJByeye5PDVHQkcfxKGRaQNLFxTh8L+HdK20 /28ni2KdqdzfonKLKdHTJvSC+I658qDaw2J4bpbFbwSHW0DX8HSVHneXW6GWJGS5e8 nQy3At3ZjSONjA/U7C9yFD0hMUm9UIQwPg8pm1e0= Sender: toke@toke.dk Received: by alrua-kau.kau.toke.dk (Postfix, from userid 1000) id 81AF1C402B3; Fri, 6 Nov 2015 12:00:27 +0100 (CET) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Jonathan Morton References: <87pozspckj.fsf@toke.dk> <6A2609D9-7747-487B-9484-ECC69C50DE96@gmx.de> <874mh3pai9.fsf@toke.dk> <50C2A7B7-1B81-41E1-B534-CA449296FE77@gmail.com> <87ziysldij.fsf@toke.dk> Date: Fri, 06 Nov 2015 12:00:27 +0100 In-Reply-To: (Jonathan Morton's message of "Thu, 5 Nov 2015 21:30:47 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87vb9fl7ec.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] Long-RTT broken again X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 11:00:58 -0000 Jonathan Morton writes: > Firstly: I can=E2=80=99t read the flent output with the version of flent > currently available to pip. It complains about =E2=80=9Cversion 3=E2=80= =9D files > being unsupported as yet. Ah, right, sorry about that. Will do a new release this afternoon :) > Running the captures through tcptrace shows that the traffic on each > flow is very bursty, and that the bursts are roughly synchronised, > leading to synchronised drop bursts. It reads like a massive > advertisement for TCP Pacing, and this time cake=E2=80=99s shaper isn=E2= =80=99t enough > to emulate it. (Perhaps a bigger buffer would sort that out.) Yup, that sounds like a reasonable explanation (and solution, given that we've seen that a bigger buffer helps). > Taking one such synchronised drop burst as representative, the sum of > outstanding data on all four flows in that direction is less than 6MB at = that > moment. This is on the version which I think you=E2=80=99ve patched, and = I assume the > figure also includes data =E2=80=9Cin flight=E2=80=9D in the delay line, = not just in cake=E2=80=99s > buffer. It=E2=80=99s difficult to reconcile that with the nominal 15MB li= mit. The > absolute peak within-flow induced delay is 150ms, which corresponds to 1.= 5MB, > not 15MB - that=E2=80=99s suspicious. > > I also get the impression that CUBIC=E2=80=99s RTT-insensitive behaviour = isn=E2=80=99t > helping matters. I=E2=80=99d be interested to see how more traditional > algorithms (Reno and Westwood+ in particular) cope with this > situation. Can re-run with Reno. > I=E2=80=99ll try to reproduce the problem locally, then see what I can do= to > fix it. Awesome! Let me know if you need more info on the setup. -Toke