From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id BA77A21F40B for ; Sat, 21 Mar 2015 09:09:22 -0700 (PDT) Received: by oier21 with SMTP id r21so112763610oie.1 for ; Sat, 21 Mar 2015 09:09:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=GUBAoD/LvcmEGPY2cy8bywXW/6VDBX//2F/xZUMU6sg=; b=xmgYvTB2JistPT3rvAlwymOKzwgd5xiReWi/aAM3Sd6pc5zkwU5DKGZnIq/Rs/lKVd K1fR3GyOVrojjDFdz873LxJBRqAiEMEy1wVeSevGsqNHzXBfBn5SGVsWEcAx18QJHP+o ChKhx4H5vuV1KolwC7PL4SneQZXV5xwJoQGTRpuDL6P6+ZYk3ff2SvHxEL8UCuKCz8hk B/FIVw1swpfLE2lwdiZaT6FXH6QhUcPGl2ADD501/oDFNliyh3bp8Xe9Ll2BbVLingzR p3m9+ZYyOc1UALxN0iSMilC0PVEmi8SWlsSd9NGhbGMOSKQINztQP0rtn6amfJFWDKN1 Ro2A== MIME-Version: 1.0 X-Received: by 10.182.78.101 with SMTP id a5mr8167505obx.45.1426954161333; Sat, 21 Mar 2015 09:09:21 -0700 (PDT) Received: by 10.202.51.66 with HTTP; Sat, 21 Mar 2015 09:09:21 -0700 (PDT) In-Reply-To: References: <7081A75C-899A-4DB7-8D77-935A37B362D8@gmail.com> <5509957B.30600@pollere.com> <491C7497-BE3E-452B-A797-C7FC1102E7ED@gmail.com> Date: Sat, 21 Mar 2015 09:09:21 -0700 Message-ID: From: Dave Taht To: Jonathan Morton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "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: Sat, 21 Mar 2015 16:09:51 -0000 In terms of a cake feature request... 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. 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. 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. 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. On Wed, Mar 18, 2015 at 2:20 PM, Dave Taht wrote: > > > On Wed, Mar 18, 2015 at 8:20 AM, Jonathan Morton > wrote: >> >> >> > On 18 Mar, 2015, at 17:10, Kathleen Nichols wrot= e: >> > >> > How are you relating target delay to bandwidth? >> >> 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 kee= ps >> things nicely under control at low bandwidths, and I find that cake rema= ins >> useful and usable even at 64Kbps (without making even the usual adjustme= nts >> to host or link configuration for such low speeds). > > > 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) > > 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 als= o > 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. > > 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. > > It also looked like cake could be poured into gates, with a bit more > research, and testing. > >> >> I can do this in cake because the shaping rate is known, whereas the pur= e >> codel and fq_codel qdiscs do not have reliable link-speed information. > > > As for this bit, we seemed to need to account for a MTU's worth of data a= t > the lower speeds, and I did not explore what fiddling with the interval a= nd > auto-calc-ing the target did at these speeds, as yet. > >> >> - Jonathan Morton >> >> _______________________________________________ >> Codel mailing list >> Codel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/codel > > > > > -- > Dave T=C3=A4ht > Let's make wifi fast, less jittery and reliable again! > > https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb --=20 Dave T=C3=A4ht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb