From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from masada.superduper.net (masada.superduper.net [85.119.82.91]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id BE38D200B29 for ; Sun, 6 May 2012 11:26:43 -0700 (PDT) Received: from 70-36-145-225.dsl.dynamic.sonic.net ([70.36.145.225] helo=[192.168.11.124]) by masada.superduper.net with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SR69G-0006AG-KD; Sun, 06 May 2012 19:25:35 +0100 Message-ID: <4FA6C21A.8060402@superduper.net> Date: Sun, 06 May 2012 11:25:30 -0700 From: Simon Barber User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120411 Thunderbird/11.0.1 MIME-Version: 1.0 To: dave taht References: <1336281092.3752.982.camel@edumazet-glaptop> <1336283203.3752.1032.camel@edumazet-glaptop> <1336315913.3752.1598.camel@edumazet-glaptop> <1336324134.3752.1825.camel@edumazet-glaptop> <4FA6B2FB.2030809@freedesktop.org> <4FA6BBDE.8070909@gmail.com> In-Reply-To: <4FA6BBDE.8070909@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.9 (--) Cc: codel@lists.bufferbloat.net Subject: Re: [Codel] usage of 'count' in codel 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, 06 May 2012 18:26:44 -0000 I was thinking the same thing (implement sfq+codel), I'm happy to refactor the codel code to be usable both standalone and with sfq, unless Eric is already doing it. Another option would be pfifofast + codel - perhaps a candidate for the default qdisc? Simon On 05/06/2012 10:58 AM, dave taht wrote: > On 05/06/2012 10:20 AM, Jim Gettys wrote: >> On 05/06/2012 01:08 PM, Eric Dumazet wrote: >>> On Sun, 2012-05-06 at 16:51 +0200, Eric Dumazet wrote: >>>> On Sun, 2012-05-06 at 07:46 +0200, Eric Dumazet wrote: >>>>> With 60 netperfs >>>>> >>>>> Using : >>>>> c = min(q->count - 1, q->count - (q->count>>4)); >>>>> q->count = max(1U, c); >>>>> >>>>> keeps count below 60000 >>>>> >>>>> qdisc codel 10: dev eth9 parent 1:1 limit 1000p minbytes 1514 >>>>> target 5.0ms interval 100.0ms >>>>> Sent 12813046129 bytes 8469317 pkt (dropped 575186, overlimits 0 >>>>> requeues 0) >>>>> rate 202366Kbit 16708pps backlog 160484b 106p requeues 0 >>>>> count 29048 delay 5.7ms drop_next 564us states 8334438 : 7880765 >>>>> 574565 621 >>>>> >>>>> >>>> I rewrote the time management to use usec resolution instead of nsec, >>>> and store it in a u32 field for practial reasons ( I would like to add >>>> codel on SFQ, so need to replicate the codel object XXX times in >>>> memory) >>>> >>>> More exactly I use 1024 nsec units (to avoid divides by 1000) >>>> >>>> And it seems I no longer have crazy q->count. >>>> >>>> Either there was a problem with the big/fat time comparaisons, either >>>> using an u32 triggers a wraparound every 4sec that cleanup the thing. >>>> >>>> More to come >>> No it doesnt work if I have non responsive flows (UDP messages). >>> >>> My queue fills, delays are high... >>> >>> The time in queue idea is good (We discussed it already), but unlike >>> RED, codel is unable to force an upper limit (aggressive drops if >>> delays are way too high) >> You are presuming that codel is the only thing running; but that's not a >> good presumption. There may be/is expected to be other fair >> queuing/classification going on at the same time. > I think codel is a very viable backend to an fq algo, and solves the > udp flood problem handily. > > and I figure eric is already halfway through ripping red out of > sfq and adding codel in its place. :) > > I've run it against qfq with good results, but more on that later. > >> An unreactive UDP flow can always cause trouble. Dropping packets can >> only be useful if the end points notice and do something about it. > yes. udp foods are a problem in drop-tail too. >> I sort of think that having some upper queue time bound makes sense, if >> only to ensure that TCP's quadratic (un)responsiveness never gets out of >> hand. > Well, we had to put in an upper packet limit anyway. >> But we agreed that having an implementation we could play with to >> observe reality would likely be better than hand-waving with no >> experience about how long the queue should be allowed to grow. > yes. > > and it really is awesome in all the versions so far. What > eric did this morning is LOVELY. > >> >> And can we *please* get this discussion back on the mailing list? > > Well, we were afraid we'd found something grievously wrong with codel > rather than our code, or had missed a 4th state in the machine > > All the same, count can grow out of control and something like this > seems to help, although it's not as smooth on the downside... > > /* > * if min went above target close to when we last went below it > * assume that the drop rate that controlled the queue on the > * last cycle is a good starting point to control it now. > */ > if (codel_time_after(now - q->drop_next, 16 * q->interval)) { > // u32 c = min(q->count - 1, q->count - (q->count >> 4)); > u32 c = q->count >> 1; > q->count = max(1U, c); > > > I figure eric will post to the mailing list before he crashes. > >> - Jim >> >> >> >> > > _______________________________________________ > Codel mailing list > Codel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/codel