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 E4AEA21F8C9 for ; Sat, 7 Nov 2015 08:34:51 -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=1446914088; bh=6MqY6YqQTsNTVBvpJzMuiXhjBSSbkmwUib7Whr0w0W8=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=LKyPbz+ggU/lQa6L18LEwXOmtKkKuyVy2s7qjAV/2Dr137dnlXflrPZP3RSjObf81 7mEo+I3RlFoy7M8Yci3FqJHlTPIUkhHO33yqOn8yWgaV1xQ96ny2jN0XH2SS3gnqX4 hv2nEVmsjA/8jZ2/j6fdamK9ksad0VHpFQhyTrUs= Received: by alrua-karlstad.karlstad.toke.dk (Postfix, from userid 1000) id C0D094FA46C; Sat, 7 Nov 2015 17:34:46 +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> <87vb9fl7ec.fsf@toke.dk> <87611fkyd7.fsf@toke.dk> <340E3F23-2F9C-449F-ACA7-86031FBE3B31@gmail.com> <87y4eambyd.fsf@alrua-karlstad.karlstad.toke.dk> Date: Sat, 07 Nov 2015 17:34:46 +0100 In-Reply-To: (Jonathan Morton's message of "Sat, 7 Nov 2015 15:06:20 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87egg1n4yh.fsf@alrua-karlstad.karlstad.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: Sat, 07 Nov 2015 16:35:14 -0000 Jonathan Morton writes: > Okay, that seems to be working somewhat better now. I=E2=80=99m still not > getting 100Mbps throughput in either direction, but now it seems to be > because the receive windows won=E2=80=99t open far enough - there=E2=80= =99s enough > buffering to prevent any packet loss. Yup, re-ran the tests in the testbed, and cake does indeed achieve the full throughput now. Awesome! :) Reno still goes out of slow start too early and doesn't hit full capacity. And for some reason the reno results are asymmetrical. I'm guessing it's due to random timing errors, though; unless someone else has another idea? Test data in the same directory as before; look at the time stamps :) -Toke