From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (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 13EBE200CCC for ; Sat, 5 May 2012 10:22:33 -0700 (PDT) Received: by wibhn6 with SMTP id hn6so2074514wib.10 for ; Sat, 05 May 2012 10:22:32 -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=FcCVcu3l+cU2JBf+QVx7DgdDIxiemUJHVBBupfhOpcw=; b=YAJeO7oedChmSgT3ggXHD8WzuEsUPbnqMWMy3213EzIZDxA+IQLd1okoQU4Uz6+kTi lGB96nG745C/xP+CDYWsmL2BBh9Mn7GFn9P4Yt682TXISzPVjG1Onp+ddEAo9sw0mKJv pJMB15tQwx5X+wls3GUUYPZgas988Dl0R2SjgT/uYlff5At5SwjbpIRPyb17D3EUky4s GTTkVvJC5tfNdLg4xtDzYod4y2BQYrZNN9iXQAgMhz7P5OAre1WZCfOHSBvXboD0ZTSh 3VzmiyjLHRNWBP/THIortPn9egXHCCEGS872+355Sca3boPWEUyT5DGUMGBGwEgKxDWO 6EzA== MIME-Version: 1.0 Received: by 10.180.105.69 with SMTP id gk5mr25523680wib.3.1336238551958; Sat, 05 May 2012 10:22:31 -0700 (PDT) Received: by 10.223.112.66 with HTTP; Sat, 5 May 2012 10:22:31 -0700 (PDT) In-Reply-To: <1336237654.3752.524.camel@edumazet-glaptop> References: <1336217671-20384-1-git-send-email-dave.taht@bufferbloat.net> <1336218794.3752.508.camel@edumazet-glaptop> <1336229343.3752.516.camel@edumazet-glaptop> <1336237654.3752.524.camel@edumazet-glaptop> Date: Sat, 5 May 2012 10:22:31 -0700 Message-ID: From: Dave Taht To: Eric Dumazet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: codel@lists.bufferbloat.net, =?ISO-8859-1?Q?Dave_T=E4ht?= Subject: Re: [Codel] [PATCH v5] pkt_sched: codel: Controlled Delay AQM 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, 05 May 2012 17:22:34 -0000 On Sat, May 5, 2012 at 10:07 AM, Eric Dumazet wrot= e: > On Sat, 2012-05-05 at 09:11 -0700, Dave Taht wrote: >> Nice! >> >> Nits: >> >> 0) I figure you already have an iproute2 patch that you can send? >> =A0 =A0 I thought 5 hours ago I had almost, but not entirely grokked net= link. >> =A0 =A0 The way you just did it was not at all how I thought it worked. = :/ >> =A0 =A0 but I will read. > > > I'll send it ( I am currently with friends ...), but you dont need it to > use codel with default params : > > qdisc add dev $DEV parent 1:1 handle 10: est 1sec 4sec codel yep. >> 1) I take it if a limit is not specified or set here, sch->limit comes >> from txqueuelen? > > No, you set a default limit of 1000 in your patch If I didn't set that at all, where does it come from? (never mind I can find it, enjoy your saturday!) > >> =A0 =A0 I do kind of like infinite queues (and angels dancing on the hea= ds of pins) >> 2) I woke up with a mod that could do ecn. I'll do an rfc patch > > Not sure it can play, if all packets are ECN, you need to drop at some > point. Yea, that's where blue had a few ideas, but the right thing is to setup some long rtts and see what happens. >> . >> 3) Tom's already on the list > ok >> 4) I'd like to play with this a lot (and have others do so too) before >> it goes upstream, >> =A0 =A0 gain kathie and vans blessing, etc. Couple weeks? (see 2). In >> particular I was >> =A0 =A0 hoping to see actual pings under load match the target setting. >> I'll get this >> =A0 =A0 going on two boxes and see what happens... play with bql, htb, e= tc... > > Hey, you'll send the patch when ready. ok! > >> 5) thought the * 16 could be efficiently implemented by the compiler, >> and saves a mem >> =A0 =A0 access. > > Well, just see the code on x86_32, the ktime conversion is expensive. > Access to memory is free since cache line is already in cpu cache. on everything but the x86_32 (do people still use that? :)). I would think on the x86_64 and mips (16 bit memory bus) would be cheaper... but it's rather a nit regardless. > > By the way, I found the precalculated array of 64 values is not really > useful, we have q->count > 64 most of the time with 2 flows. yea, just noticed that. I figured 25 wasn't enough, didn't think 64 was either. will get some data on various flows and find a better value. > >> 6) unless 2) happens we can kill q->flags > > Yes Enjoy your saturday! > > > --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net