From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) (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 A1314200AEE for ; Sun, 6 May 2012 10:21:02 -0700 (PDT) Received: by qcsp15 with SMTP id p15so4794273qcs.16 for ; Sun, 06 May 2012 10:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=v73Cv842Bl0raqRzuPqc8Z2D8ezBfOimwQlSsXHk6LM=; b=skVsrt1vCJLrAIKAF8oH4JhP+EUuSNelqM/lizPyNO+cQUlVOwjoS6sPYuBXTC35ns F8M4QXws42kATFEq+PJTByCorySB/Ol4VJdXgMHnXFBBtjDJE/mZ6i19ZkMA93GffMgc IbXwetpHl/uK7Ivj166dnXhVrqSOx7jim07MEfW8FunDc1CMQAAI5/KNyVFSKMuewSpf fLZohvwaZrmIyIuLt2mFvSjfiOzhIJnl39alCZqaxk6MwQbcsrj/oCENdq+3+0TXtgcM +e0qzmS087onxGEmeln9wivxhZjD/Obz5u2J9w2TJBN+KzvpyeCv1p8+CImKlnsGGsdz QT2A== Received: by 10.224.217.138 with SMTP id hm10mr20572694qab.76.1336324861141; Sun, 06 May 2012 10:21:01 -0700 (PDT) Received: from [192.168.1.144] (c-50-138-162-108.hsd1.ma.comcast.net. [50.138.162.108]) by mx.google.com with ESMTPS id df8sm28111199qab.6.2012.05.06.10.20.59 (version=SSLv3 cipher=OTHER); Sun, 06 May 2012 10:21:00 -0700 (PDT) Sender: Jim Gettys Message-ID: <4FA6B2FB.2030809@freedesktop.org> Date: Sun, 06 May 2012 13:20:59 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Eric Dumazet , codel@lists.bufferbloat.net 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> In-Reply-To: <1336324134.3752.1825.camel@edumazet-glaptop> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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:21:03 -0000 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. An unreactive UDP flow can always cause trouble. Dropping packets can only be useful if the end points notice and do something about it. 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. 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. And can we *please* get this discussion back on the mailing list? - Jim