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 DA20221F760 for ; Thu, 5 Nov 2015 06:36:08 -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=1446734164; bh=mp9raauhu78blQZWhTwSOoYWV4t9k06aQXzH/xOeKh4=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=lm0qzV+oxsBDzTz+NMbKr6XDXDKANdaxHvfxOP4LxGjUS4bFi66MTp73EhSuijc0/ jOib/iLwKJ/NyNAtFhfEGY34AWF9zbUK0oA2pzfE8Fx2QBA4ZN+lk5RrXbCOZ3gtgp eDI2MTuP7qBKP6UoNwayMoKWaC/lgTz4bCI3Pq3Y= Sender: toke@toke.dk Received: by alrua-kau.kau.toke.dk (Postfix, from userid 1000) id 2A061C402B3; Thu, 5 Nov 2015 15:36:04 +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> Date: Thu, 05 Nov 2015 15:36:04 +0100 In-Reply-To: <50C2A7B7-1B81-41E1-B534-CA449296FE77@gmail.com> (Jonathan Morton's message of "Tue, 3 Nov 2015 18:43:12 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87ziysldij.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: Thu, 05 Nov 2015 14:36:31 -0000 Jonathan Morton writes: > So, again - what=E2=80=99s going on? Are there any clues in packet traces > with sequence analysis? So, reran and took traces. Data and packet dumps at: https://kau.toke.dk/experiments/cake/longrtt/ There's two runs: the first one is what's in git now, the second one patches the byte accounting to use the packet length rather than the truesize, which helps a bit but is still inadequate. The packet dumps and cake stats output agree: cake is running out of buffer size. ECN is enabled on this test, and there's not a single mark performed, but several thousand drops. So something is definitely wrong with the buffer sizing. -Toke