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 3D1D321F820 for ; Wed, 28 Oct 2015 09:34:11 -0700 (PDT) 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=1446050048; bh=S8dKaJABzjp0yfNfMm94SVY3HqEeJ0kPEjaSekV762c=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=uNGvQY+TIwJyfhvm679SVm5/awOk76s+3nSnumy1kyetOhRiGI/RHJlglst2dIt/u igYvUYRS6/O/1Dg6KoU7PPjBNS2z19rKAw1ZhNMB24V5Ik1Ek5ji3+EbZswT6wzy3X SDYpKlj16m7XXFAhE2+t7oermyI6a/q4gxWK8HVA= Received: by alrua-kau.kau.toke.dk (Postfix, from userid 1000) id A733BC40239; Wed, 28 Oct 2015 17:34:07 +0100 (CET) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Sebastian Moeller References: <87a8r4mji9.fsf@toke.dk> <751BA26E-3CC7-4341-99C6-2448111A07B4@gmx.de> <87pozzkns6.fsf@toke.dk> Date: Wed, 28 Oct 2015 17:34:07 +0100 In-Reply-To: (Sebastian Moeller's message of "Wed, 28 Oct 2015 16:50:56 +0100") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87lhankl4w.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] Running Cake at long RTTs 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: Wed, 28 Oct 2015 16:34:34 -0000 Sebastian Moeller writes: > Hi Toke, > > On Oct 28, 2015, at 16:36 , Toke H=C3=B8iland-J=C3=B8rgensen wrote: > >> Sebastian Moeller writes: >>=20 >>> Except I requested rtf 120 ms and got 122.7, which admittedly is >>> close. I know I repeat myself, but on of the is one things that >>> irritate me in software is if software silently pretends to know >>> better=E2=80=A6 Now 122.7 versus 120 might be in the noise, but look at= that: >>=20 >> I don't remember from where, but I suspect there's something wrong with >> the 'change' logic in Cake. Can you try removing the qdisc completely, >> then re-adding it, rather than doing a straight replace? > > Good point: > moeller@happy-horse:~/CODE/sch_cake> sudo tc-toke qdisc replace dev eth0 = root pfifo_fast > moeller@happy-horse:~/CODE/sch_cake> sudo tc-toke qdisc replace dev eth0 = root cake bandwidth 1Mbit besteffort rtt 100ms ; sudo tc-toke -s qdisc Right, so there's definitely a bug in the 'change' logic. > Just 95 is not equal to 100 either=E2=80=A6 That's also a bug as far as I'm concerned. > At least in full automatic mode I would have assumed cake would also > increase the interval according to the available bandwidth in the > different Tins... What has the interval got to do with the bandwidth? There's definitely some value in capping the target to be at least the time it takes to transmit one MTU's worth of data. > All the additional parameters are there to tweak and experiment. So I > argue exposing knobs is not making it difficult to configure as long > as nobody needs to touch these (I also volunteer to make the tc help > more specific in that regard=E2=80=A6) If no one needs to touch them, why are they there? At best that will just make things break when they bitrot. I can see how getting around the need for the encapsulation variables is going to be hard; but for the target, I am not sure I see the value in exposing this for "experimentation". If we are sure that the relation between target and interval should be fixed (and I'm not entirely convinced of that yet, but will think about it some more), then exposing target is just going to enable invalid configurations. -Toke