From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 C65C121F2BD; Wed, 18 Mar 2015 00:22:09 -0700 (PDT) Received: from [10.155.214.236] ([80.187.113.57]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MZCUG-1YohmK3iiC-00KwwC; Wed, 18 Mar 2015 08:22:05 +0100 User-Agent: K-9 Mail for Android In-Reply-To: <7081A75C-899A-4DB7-8D77-935A37B362D8@gmail.com> References: <7081A75C-899A-4DB7-8D77-935A37B362D8@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable From: Sebastian Moeller Date: Wed, 18 Mar 2015 08:22:00 +0100 To: Jonathan Morton , codel@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net Message-ID: X-Provags-ID: V03:K0:716UoiGx8AqSwm+VpuU7iao8rSPMLBhPjUuEBS6C4UVzgVsG7Pw l19gPNMwE5IQ3/kU55SpdoX3gafQtQFFT3Rd5AK2VfYa7h9pyTQJXshyzwlv0YE7cybcC3a wYLph0MN6V4QOwtMJoFCI8xbkroGKvf4wtSnvZc+svAhw9Ve7egcoGf6TulF+/qO15CKE+T H/CUsIWhyqBUEvIx5ZKOA== X-UI-Out-Filterresults: notjunk:1; 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: Wed, 18 Mar 2015 07:22:38 -0000 Hi Jonathan, Great work=2E @Dave is there a cerowrt or openwrt build around that includ= es cake? On March 17, 2015 9:08:39 PM GMT+01:00, Jonathan Morton wrote: >After far too long, it looks like I=E2=80=99ll have the opportunity to wo= rk on >sch_cake a bit more=2E So here=E2=80=99s a little bit of a =E2=80=9Cstat= e of the union=E2=80=9D >speech about what we=E2=80=99ve got and what I=E2=80=99m planing to add t= o it=2E > >So far we=E2=80=99ve got a deficit-mode, non-bursting shaper that works p= retty >well, and an integrated implementation of fq_codel that tunes itself >(that is, the target delay) to the bandwidth set on the shaper=2E The >configuration is =E2=80=9Cas easy as cake=E2=80=9D; the intention is that= you can just >specify one parameter (the bandwidth to shape at) and leave everything >else at the defaults; there simply aren=E2=80=99t very many visible knobs= , >because they aren=E2=80=99t needed=2E > >We=E2=80=99ve also got Diffserv classification, and that part hasn=E2=80= =99t been so >successful=2E Each class grabs all traffic with some subset of the >codepoints, and stuffs them into a separate shaper+fq_codel instance, >and the higher-priority shapers steal bandwidth from the lower ones to >enforce priority=2E High-priority classes can only use a limited amount >of bandwidth, exactly as specified in generic Diffserv PHBs=2E > >It works, perfectly as designed, but the resulting behaviour isn=E2=80=99= t >particularly desirable from an end-user perspective=2E In particular, >people run tests using best-effort traffic to see how much bandwidth >they=E2=80=99re getting, resulting in complaints that cake had to be give= n a >bigger number to get the correct throughput - which of course also >stops it from functioning correctly when background traffic is added to >the mix=2E So that needed a rethink=2E I wonder, are the low priority classes configured with a guaranteed minimu= m bandwidth to avoid starvation? And will they opportunistically grab all l= eft over bandwidth to fill the pipe? Then speed test should just work as lo= ng as there is no competing traffic=2E=2E=2E > >Incidentally, the existing Diffserv implementation can be disabled by >specifying the =E2=80=9Cbesteffort=E2=80=9D keyword=2E This lumps all tr= affic into a >single class, handled by a single shaper at the configured rate=2E Cake >already works pretty well in that mode; sometimes I turn the shaper >down to analogue-modem speeds and note, with some satisfaction, that >everything *still* works=2E Except YouTube, but that=E2=80=99s only beca= use >streaming video really does need more than analogue-modem bandwidth=2E > >As for performance, I=E2=80=99m able to make my ancient Pentium-MMX shape= at >over 50 Mbps, summing traffic in both directions between two bridged >Fast Ethernet cards=2E This limitation is probably a combination of >timer latency and context-switch overhead=2E I don=E2=80=99t expect it t= o >improve much, unless we find a way to seriously reduce those overheads >(which are already quite low for a modern desktop OS)=2E A faster >machine with better timers gets better performance, of course=2E I am probably out of my mind, but couldn't it help if cake would allow a f= ixed cycle mode where it would process 50ms or so worth of packets pass the= m to the interface, and then sleep until the next 50ms block start=2E This = should just be a fallback mode to not degrade badly under overload; I would= hope that could help, as it will be far fewer timers to handle and maybe l= ess context switching, as I would guess cake processing happens entirely in= kernel space=2E I probably am overlooking something that makes my idea a non-starte= r ;) > >So there are two big things I want to change in the next version: > >The easy part (at least in terms of how many unknowns there are) is >adjusting the flow-queueing part so that it uses set-associative >hashing instead of straight hashing when selecting a queue=2E This >should reduce the incidence of hash collisions considerably for a given >number of flow queues, or conversely provide equivalent collision >performance with a smaller number of queues=2E > >The more interesting part is to rework the Diffserv prioritiser so that >it behaves more usefully=2E I think I=E2=80=99ve hit upon the right idea= which >should make this work in practice - instead of individually >hard-shaping each class, instead use the shaper logic as a threshold >function between high and low priority, and instead implement a single >shaper to handle all traffic=2E The priority function can then be >handled by a weighted DRR system - which is already in place, but >doesn=E2=80=99t do much - with just that small modification for changing = the >weights based on the shaper state=2E > >So high-priority traffic gets high priority - but only if it limits >itself to a reasonable bandwidth=2E Above that bandwidth, it gets low >priority, but is still able to use the full shaped bandwidth if nobody >else contends for it=2E =20 I think the highest priority band should only get its bandwidth qu= ota, and have no silent priority demotion; but otherwise I think that idea = that classes can pick up unused bandwidth sounds sane, especially for best = effort and background=2E And (unlike say HFSC) we need precisely two >parameters per class to do this, both specified as ratios rather than >hard bandwidth numbers: a bandwidth share (which determines both the >shaper setting and the low-priority-mode DRR weighting) and a priority >factor (which determines the high-priority-mode DRR weighting)=2E So if >those knobs end up being exposed to userspace, they=E2=80=99ll be easier = to >understand and thus use correctly=2E > >All of this feeds my main goal with Diffserv, which is to start giving >applications natural incentives to mark their traffic appropriately=2E=20 >Each class has both an advantage, and a tradeoff which must be accepted >to realise that advantage=2E If you need absolutely minimal latency, you >can choose a high-priority class, but you=E2=80=99ll have to be frugal ab= out >bandwidth=2E If you need maximum throughput, you=E2=80=99ll have to put = up with >reduced priority compared to latency-sensitive traffic=2E And if you >want to be altruistic, you can choose to mark your stuff as bulk, >background traffic, and it=E2=80=99ll be treated accordingly=2E All of t= his is >in accordance with existing RFCs=2E > >A small caveat: cake is not designed for wifi=2E It=E2=80=99s designed f= or links >that can at least be treated as full-duplex to a close approximation=2E= =20 >Shared-medium links *can* behave like that, if they=E2=80=99re shaped to = a >miserly enough degree, but we really need something different for wifi >- although several of cake=E2=80=99s components and ideas could be used i= n such >a qdisc=2E > >Roll on cake3=2E > > - Jonathan Morton Many thanks and best regards Sebastian > >_______________________________________________ >Codel mailing list >Codel@lists=2Ebufferbloat=2Enet >https://lists=2Ebufferbloat=2Enet/listinfo/codel --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E