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 did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id B083921F0F4 for ; Mon, 27 Aug 2012 07:17:10 -0700 (PDT) Received: by wibhm2 with SMTP id hm2so2518887wib.10 for ; Mon, 27 Aug 2012 07:17:08 -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=48X5GKgVapognlJB2t/Q6TA0f8Q36c8PjrKW6QjlBcI=; b=Tl8JFSsYhxWuWAccwfenqSsBy3ZEmfpdaSH/J/Gb9v34Wi8Som683TLGrSUdYn44E8 rX+qYzFEQb4ndwDQ84iuwTwTDK7B6v7DTGJX9h1s++8jEpqPu3iG13Gq+TIvwbZSvRFp kyjRhiCJ1LD0DXKw2qDIyko946Y1cwyoD9UmZ34f/O3yPLczWT2ASyGAfZC0w+AwhF0e kuCpvlm+iO3+4dpbrvS4zXDCTJSYw/eJuxwYH4PGYqAYj8MS4Bst6UBPbDRWa6irlb5K /palsaE0uzyxXgwmZi1cGFn7oFPWEks83WpgxJhM9YoYV6oFQpFSq9eciF8m5LbTnGIi idAg== MIME-Version: 1.0 Received: by 10.180.107.103 with SMTP id hb7mr26003860wib.3.1346077028450; Mon, 27 Aug 2012 07:17:08 -0700 (PDT) Received: by 10.223.159.134 with HTTP; Mon, 27 Aug 2012 07:17:08 -0700 (PDT) In-Reply-To: <1346069879.2420.249.camel@edumazet-glaptop> References: <1346007773-26679-1-git-send-email-dave.taht@bufferbloat.net> <1346007773-26679-2-git-send-email-dave.taht@bufferbloat.net> <1346069879.2420.249.camel@edumazet-glaptop> Date: Mon, 27 Aug 2012 07:17:08 -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] [RFC PATCH] codel: tighten responsiveness and more reliably deal with loads 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: Mon, 27 Aug 2012 14:17:11 -0000 On Mon, Aug 27, 2012 at 5:17 AM, Eric Dumazet wrot= e: > On Sun, 2012-08-26 at 12:02 -0700, Dave T=E4ht wrote: >> From: Dave Taht >> >> This updates the codel algorithm to more closely match the current >> experimental ns2 code. Not presently recomended for mainline. >> >> 1) It shortens the search for the minimum by reducing the window over >> the intervals and re-running the control law to better schedule >> the estimate. >> 2) Holds onto the drop schedule harder when re-entering drop state. >> 3) Corrects for newton method running in reverse. >> >> --- >> include/net/codel.h | 39 +++++++++++++++++++++++---------------- >> 1 file changed, 23 insertions(+), 16 deletions(-) >> >> diff --git a/include/net/codel.h b/include/net/codel.h >> index 389cf62..57031ad 100644 >> --- a/include/net/codel.h >> +++ b/include/net/codel.h > >> + codel_Newton_step(vars); >> + codel_Newton_step(vars); > > This makes no sense for several reasons : > > 1) If we do the vars->count =3D 1; > vars->rec_inv_sqrt =3D ~0U >> REC_INV_SQRT_SHIFT; > > Then there is no need of _any_ Newton steps. > The rec_inv_sqrt value is the good one. > > 2) If we change vars->count to vars->count - 2 > Then a single step is enough. > The double newton step now is an artifact of when count could jump from one large number to a smaller one. It didn't hurt, I didn't feel like thinking about it, and I wanted to match the behavior of a real sqrt and the model more exactly. I thought really hard about ripping it out and going back to the invsqrt code, too. I also fiddled with the clock... > > I can understand that with the current way : > > vars->count =3D vars->count - vars->lastcount > > then we can have a slight error, but this gave no difference in codel > experimental behavior. Actually the error could be quite large. (as in off by a factor of 2) > I would say that codel response to bad queue is pretty easy (doing count > ++ at each drop), but changes in count to adapt to oscillations between > good and bad queues is yet to be investigated. > > Do we have to do > 0) current way (count - lastcount) > 1) count =3D count - 1 > 2) count =3D count - 2 > 3) count =3D count * 88% > 4) count =3D count * 75% > 5) count =3D count * 50% > 6) count =3D count * 25% > 7) count =3D some clever function using history of previous changes > ... > > In my prior tests, 1) and 2) were pretty bad, I am sure it is not the > right way. I was *utterly sure* it was not the right way, either, then (after fiddling with various variants of the above for a month), only then I implemented kathie's change to do the control_law inside of ok_to_drop... ... and count-2 worked much better than I expected. Please note that kathie and van aren't satisfied with this variant either, but do try it... > (the count =3D 1 is only done when queue was idle for a long time) See the additional placement of the control law. > > > _______________________________________________ > Codel mailing list > Codel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/codel --=20 Dave T=E4ht http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-17 is out with fq_codel!"