From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 2767D200AEE for ; Sun, 6 May 2012 10:58:58 -0700 (PDT) Received: by pbcwz7 with SMTP id wz7so9942837pbc.16 for ; Sun, 06 May 2012 10:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=aiP21LOCnllaS1DCqGBP3j1bPIxcVKRK2sZLqWUQiFA=; b=jiResvd29jtD1900t0emUp7ZrVpk0zK4T+kXA5ND/4NeY9bhnZYiKJVUzZHw3CgCFM 0cprGxo83/wDJEZbtXcmcGgb3pv8xSYgTNfmCiaPK46/ZcnQfDMqEWwncRp8aFN5je7m VWc5LSUaaBq/IjsILvteeMY65F8TWUPySSUixkJZnt0FFAXON+g3pLHL6o9YtM2d++Wb ifeWRrTkFz6wMaZ3U9eHORY4pFodmutD+jtw97m4yPB3eKuP6KfT3ixzvF2T/mxZOKFa ImisjuALTZxAgWsK/tU+2ilNL1tPYjsJf5bOhkEfhGHYXLuaph/G7wBoj9PMyQ7saXaz uPZA== Received: by 10.68.201.65 with SMTP id jy1mr19174975pbc.5.1336327137591; Sun, 06 May 2012 10:58:57 -0700 (PDT) Received: from ?IPv6:2001:4f8:3:203::c001? ([2001:4f8:3:203::c001]) by mx.google.com with ESMTPS id uu3sm15541397pbc.70.2012.05.06.10.58.55 (version=SSLv3 cipher=OTHER); Sun, 06 May 2012 10:58:56 -0700 (PDT) Message-ID: <4FA6BBDE.8070909@gmail.com> Date: Sun, 06 May 2012 10:58:54 -0700 From: dave taht User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Jim Gettys 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> In-Reply-To: <4FA6B2FB.2030809@freedesktop.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 17:58:58 -0000 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 > > > >