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 816C421F5D0 for ; Tue, 27 Oct 2015 09:50:38 -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=1445964635; bh=MnLuSaLcX42ROABWlvtXnIDHY6TLeKG0lzwkCZQgkI4=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=mQJnPld92iZQdPfQ8h7O39OVL9LHIKQmuvIvA01L6ILNyj5jNSA9EpHzFdDjzg3tC scknznlKj2rP52YcpSa7XdedhJKEYVPKJKT5+Gkj2T9CZhCabmz1T7EsTE1KRu36ov sCuccwGCUm6bdJhH/fiQ+Ss8jcZSsuyGgrbxaGkU= Sender: toke@toke.dk Received: by alrua-kau.kau.toke.dk (Postfix, from userid 1000) id 49D3CC4025B; Tue, 27 Oct 2015 17:50:34 +0100 (CET) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Sebastian Moeller References: <87a8r4mji9.fsf@toke.dk> <6499FF74-D13B-4B2E-90E3-D1FDD3FD1468@gmx.de> Date: Tue, 27 Oct 2015 17:50:34 +0100 In-Reply-To: <6499FF74-D13B-4B2E-90E3-D1FDD3FD1468@gmx.de> (Sebastian Moeller's message of "Tue, 27 Oct 2015 17:44:05 +0100") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <8737wwmf1h.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: Tue, 27 Oct 2015 16:51:02 -0000 Sebastian Moeller writes: >> - Turn the hard packet queue size into a lower bound rather than an >> upper bound. > > This seems dangerous for low memory configurations? Well, yeah, the max packet count allowed can be higher this way, but I guess the only sane answer to that is "don't configure cake for 100Mbit and 1s+ of latency if you don't have the memory to spare". Having the (now lower) bound be a bit lower than it is currently may be a good idea, but not sure what it should be... The current 10240 matches fq_codel. >> - Scale the target to be 1/16th of the interval. > > Codel theory claims 5-10%, so 1/20 to 1/10, so it seems you > confirm the theory, not sure why cake did not do this as a > default=E2=80=A6 rem, what actually was cake setting target to? Asked > differently how sensitive to target being exactly 1/16th was the > throughput? Yup. 1/16th has the benefit of being implementable as a 4bit shift :) Before, the target was hard-coded as 5 ms; so this was definitely an oversight. -Toke