From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id E8AD421F403 for ; Thu, 16 Apr 2015 06:49:21 -0700 (PDT) Received: from vh.zmbp.uni-tuebingen.de ([134.2.88.158]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M2ojS-1ZXool35BW-00sgTa; Thu, 16 Apr 2015 15:49:17 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: <5BC1CA30-289D-42B4-95CD-3AE5D7B96F09@gmail.com> Date: Thu, 16 Apr 2015 15:49:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <87598D1B-6A86-41CC-B38D-A14FD9FED81F@gmx.de> References: <5BC1CA30-289D-42B4-95CD-3AE5D7B96F09@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:eFGQnqjqr26m+ywEm3YGdQLDhMt1Lw8JwOkGlm2rHn32w0OM78E s0VVCsdSOzAs0cSw6gYcYP3h4FweNe3dezB9/2bdklvJnTi9NY9144cRoa4LLzbBNvsXVZQ s7nybzgeSsY0Qsd7Jx568vBN3X8dsYGFUcsCT/5TxoSmAPcPFqlCorAi7STIQFihbVm9pJt H/8Uy1ePD0YtiAcxFM5ow== X-UI-Out-Filterresults: notjunk:1; Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] Cake3 - source code and some questions 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, 16 Apr 2015 13:49:51 -0000 Hi Jonathan, On Apr 16, 2015, at 15:25 , Jonathan Morton = wrote: >=20 >> On 16 Apr, 2015, at 15:14, Adrian Popescu = wrote: >>=20 >> Will the changes to codel made by cake be put into fq_codel? >=20 > This might be a more complex question than you realise. >=20 > The most likely feature of cake to be implemented in fq_codel might be = the set-associative hash, since it=92s almost a pure win. That would = almost be a cut-and-paste operation, but due to fq_codel=92s de-facto = status as a =93standard candle=94 in research, it would need to be made = configurable, at least to make turning it off easy. And that isn=92t = really a =93codel=94 feature change, since it influences the FQ layer = exclusively. >=20 > The codel parameter tuning done by cake isn=92t applicable to = fq_codel, because the bandwidth information that this tuning relies on = isn=92t available (not even when it=92s stacked with HTB). That=92s why = cake defaults to something very like the standard codel parameters when = the internal shaper is disabled (=93unlimited=94 mode), That makes me wonder, is there a way to specify =93fixed=94 = target and interval values for the codel part of cake sort of to = override the default automatic selection while still using the shaper? = This might make for a compelling demonstration of the beauty of the = automatic mode to convince skeptics. Best Regards Sebastian > and that in turn is one reason why those defaults are also used at = "sufficiently high=94 bandwidths, so that there isn=92t a sharp = discontinuity in the behaviour when the bandwidth is increased beyond = the link rate and on to infinity (unlimited mode actually works by = setting the shaper to infinite bandwidth, ie. zero time per byte). The = other reason, as I previously noted, is because the parameters depend on = the total RTT as well as the packet rate. >=20 > Which leaves algorithmic changes to codel itself. It=92s certainly = possible to drop these (fairly subtle) changes in, but we should = probably spend some more time measuring the effects of these changes and = finalising them. We=92re considering doing a major refactor of the = code, which might make it harder to perform a drop-in replacement. In = any case, FQ does mean that codel=92s precise behaviour is less critical = than it might otherwise be, and there are valid arguments - such as the = =93standard candle=94 one - for leaving it alone. >=20 > - Jonathan Morton >=20 > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake