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 7BDFD21F803 for ; Sat, 7 Nov 2015 00:49:03 -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=1446886139; bh=LHddFGVkP+jmycESEC1h6P50SlCdBDvlDatIvODoB50=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=n1EF5/X6xct93PihiSTA+mMQCdjXuNKO/fd11QKwAi/9RVO9ImC57qNEiCW/RnEWo Z1wzpkxUcqTraJPGNBiPJ1ECwQtDYg2cbIqWFzhBbSTWl8KeANr4Ori5ozeHkG6oX5 EHuToJ10VIiKiqykMbIgirEwWMUIgfZzeWcQJVrI= Received: by alrua-karlstad.karlstad.toke.dk (Postfix, from userid 1000) id D7B0B4F9D6F; Sat, 7 Nov 2015 09:48:58 +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> Date: Sat, 07 Nov 2015 09:48:58 +0100 In-Reply-To: <340E3F23-2F9C-449F-ACA7-86031FBE3B31@gmail.com> (Jonathan Morton's message of "Sat, 7 Nov 2015 07:02:13 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87y4eambyd.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 08:49:26 -0000 Jonathan Morton writes: >> On 6 Nov, 2015, at 16:15, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >>=20 >> Added a run with Reno to the same directory. Smoother, but worse overall >> throughput. > > Yes, looks like it=E2=80=99s ramping up the slow way, and hasn=E2=80=99t = reached the > BDP by the time the test run ended. > > However, it also looks like it=E2=80=99s properly ack-clocked, unlike CUB= IC, > so while it=E2=80=99s still bursty, it isn=E2=80=99t overflowing the buff= er except > during slow-start. Hmm, right. Can run a longer test to see if it ever reaches 100Mbit; and also add in a BIFO queue for comparison. > The fact that slow-start terminates (due to loss) after only a few > RTTs is suspicious. What parameters are you giving to netem? I note > that the default packet limit in netem is 1000, which is 1.5MB... Not using netem - don't trust it. The delay is added by dummynet which is on a separate box in the middle. And dummynet basically has an infinite buffer; no packets are dropped there (yes, I checked) :) -Toke