From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 B8F3421F38A for ; Sun, 22 Mar 2015 02:39:37 -0700 (PDT) Received: from hms-beagle.home.lan ([87.164.165.7]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MGXV6-1Ymru02OrA-00DCv4; Sun, 22 Mar 2015 10:39:33 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: Date: Sun, 22 Mar 2015 10:39:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7081A75C-899A-4DB7-8D77-935A37B362D8@gmail.com> <5509957B.30600@pollere.com> <491C7497-BE3E-452B-A797-C7FC1102E7ED@gmail.com> To: =?iso-8859-1?Q?Dave_T=E4ht?= X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:sCnBVMEkjlbbVXs6+kVNcbE6/lCtrvxw1Zal88hK+fqx3ChNTBV PeIsu47Y3nHwhX+ej1en9YpnZ6P+mdhCmMiaB9sTYcWNKePQpbeHlZ/69J5sHqInLdT1NXD NiiwKkVUx5hRcUxhhI35qMUi18NbhWhJA9nicG11+1awlSouxkgU/V/tE7A8r8Vdwi1ouPW wAgHsM45Kn14cdNJ/rp4A== X-UI-Out-Filterresults: notjunk:1; Cc: Jonathan Morton , "codel@lists.bufferbloat.net" Subject: Re: [Codel] The next slice of cake X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 09:40:06 -0000 Hi Dave, hi Jonathan, On Mar 21, 2015, at 17:09 , Dave Taht wrote: > In terms of a cake feature request... >=20 > fq_codel has a maximum number of packets limit, which is set very > large (10000) to accommodate 10GigE. It is arbitrarily patched down in > openwrt (1000), and reduced still further by the sqm-scripts (also > arbitrarily), to reduce the impact of a packet flood on machines with > very little memory. >=20 > I would like cake to have a byte limit instead. Now, per packet > overhead in linux is very high, something like 256 extra bytes per > packet (4x1 vs the smallest size). However, a packet limit can be much > harder on memory than that - overhead be as large as 64k per "packet" > on TSO/GSO enabled systems, (dynamic range of 1x1000!), vs using a > byte limit which would only have issues with lots of small packets. I could be out to lunch here, as usual,;but I argue the byte = limit should include the kernel overhead (could this be based on = skb->truesize) as this is what cunts against real memory. My assumption = here is that in normal operation we rarely/never get queues to fill up = to the limit anyways (as tho would turn the queue into tail-drop = effectively), but if we do we really need to account for the worst case = (especially on home routers). What do you think? Best Regards Sebastian >=20 > cake's bandwidth parameter can easily set a desirable max byte limit > at (say) 2 or 4x the BDP, and key off of that and not bother to track > a per packet limit. >=20 > It would be nice for cake (without shaping enabled) to be about to > automatically sense the actual interface rate and size this outer > limit appropriately, but I don't think mechanisms exist to do that. >=20 >=20 > On Wed, Mar 18, 2015 at 2:20 PM, Dave Taht = wrote: >>=20 >>=20 >> On Wed, Mar 18, 2015 at 8:20 AM, Jonathan Morton = >> wrote: >>>=20 >>>=20 >>>> On 18 Mar, 2015, at 17:10, Kathleen Nichols = wrote: >>>>=20 >>>> How are you relating target delay to bandwidth? >>>=20 >>> Essentially, I use 5ms as a minimum, and increase it if necessary to >>> accommodate a couple of MTU-sized packets at the shaping rate. This = keeps >>> things nicely under control at low bandwidths, and I find that cake = remains >>> useful and usable even at 64Kbps (without making even the usual = adjustments >>> to host or link configuration for such low speeds). >>=20 >>=20 >> In the cake2 (or maybe it was the unpublished cake3) version, I had a >> lighter weight version of the codel algorithm, that did not have a = target >> parameter at all. Instead it just took the interval parameter and = shifted it >> right 4 (yielding a target of 6.xms from an interval of 100ms) >>=20 >> This saves on a memory access (and storage per queue!) , and I felt = that any >> differences in behavior would be unnoticeable. And they were. This is = also >> above the bound for cable-modem media access that greg white (rightly = or >> wrongly) believed existed. So I have no problem in eliminating = "target" >> entirely. >>=20 >> Cake (without bandwidth shaping engaged) uses more cpu than fq_codel = did and >> this was one of many optimizations I'd attempted (or successfully = added). >> Cake with shaping is a bit less cpu than sqm-scripts htb + fq_codel + >> filters. >>=20 >> It also looked like cake could be poured into gates, with a bit more >> research, and testing. >>=20 >>>=20 >>> I can do this in cake because the shaping rate is known, whereas the = pure >>> codel and fq_codel qdiscs do not have reliable link-speed = information. >>=20 >>=20 >> As for this bit, we seemed to need to account for a MTU's worth of = data at >> the lower speeds, and I did not explore what fiddling with the = interval and >> auto-calc-ing the target did at these speeds, as yet. >>=20 >>>=20 >>> - Jonathan Morton >>>=20 >>> _______________________________________________ >>> Codel mailing list >>> Codel@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/codel >>=20 >>=20 >>=20 >>=20 >> -- >> Dave T=E4ht >> Let's make wifi fast, less jittery and reliable again! >>=20 >> https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb >=20 >=20 >=20 > --=20 > Dave T=E4ht > Let's make wifi fast, less jittery and reliable again! >=20 > https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb > _______________________________________________ > Codel mailing list > Codel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/codel