From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pz0-f48.google.com (mail-pz0-f48.google.com [209.85.210.48]) (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 03888200CCC for ; Sat, 5 May 2012 16:15:21 -0700 (PDT) Received: by dadz8 with SMTP id z8so1815231dad.7 for ; Sat, 05 May 2012 16:15:21 -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; bh=DGTaSFBIs5ee3+llmrUDERfRgPMSluubz0WikTzFOm4=; b=Nz4Ejo3ZAmssWV6LTTMDCHRUXmm+DSp6W3wxVuw/mEHve11KL6ahJrIoy+OQQ+6yKZ +shYsU2SR/yJ1a7ww7gsll4ybuH2XJIhU6uVGzhiH18j9eoQkLsoH0ehABzTA5CQrlp5 9aaaDaM5jlqc+jl9HgagfGM/AIAOzMsTdVCv4CMuFiPIhVtHPYeUrfx+e8fWyrw4a8ps weKRJGYsh06pAb+E5DYu4SQG2AA8VUm2N1FSIWdEtFBTxBaw1Dee61hxwmDB+78EHOPx tRBxXNw7WQmJa21yrottwCMYLraYi318nEPq8f6JfS8qJiOsgS7W2Vo1zCls2M3YdL3N RarA== Received: by 10.68.231.195 with SMTP id ti3mr273345pbc.96.1336259721557; Sat, 05 May 2012 16:15:21 -0700 (PDT) Received: from ?IPv6:2001:4f8:3:203::c001? ([2001:4f8:3:203::c001]) by mx.google.com with ESMTPS id vi7sm1290710pbc.38.2012.05.05.16.15.19 (version=SSLv3 cipher=OTHER); Sat, 05 May 2012 16:15:20 -0700 (PDT) Message-ID: <4FA5B486.40307@gmail.com> Date: Sat, 05 May 2012 16:15:18 -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: Eric Dumazet References: <1336217671-20384-1-git-send-email-dave.taht@bufferbloat.net> <1336218794.3752.508.camel@edumazet-glaptop> <1336229343.3752.516.camel@edumazet-glaptop> <1336249251.3752.558.camel@edumazet-glaptop> <1336250168.3752.560.camel@edumazet-glaptop> <1336252281.3752.561.camel@edumazet-glaptop> <4FA597C0.7090206@gmail.com> <1336252832.3752.563.camel@edumazet-glaptop> <4FA5A3B8.7020808@gmail.com> <1336255783.3752.573.camel@edumazet-glaptop> <4FA5AB05.9030305@gmail.com> <1336257554.3752.578.camel@edumazet-glaptop> <4FA5AE25.1080506@gmail.com> <4FA5B320.8050207@gmail.com> In-Reply-To: <4FA5B320.8050207@gmail.com> Content-Type: multipart/alternative; boundary="------------070409000002090502050903" Cc: codel@lists.bufferbloat.net, =?UTF-8?B?RGF2ZSBUw6RodA==?= 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 23:15:22 -0000 This is a multi-part message in MIME format. --------------070409000002090502050903 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 05/05/2012 04:09 PM, dave taht wrote: > On 05/05/2012 03:48 PM, dave taht wrote: >> On 05/05/2012 03:39 PM, Eric Dumazet wrote: >>> On Sat, 2012-05-05 at 15:34 -0700, dave taht wrote: >>>> On 05/05/2012 03:09 PM, Eric Dumazet wrote: >>>>> On Sat, 2012-05-05 at 15:03 -0700, dave taht wrote: >>>>> >>>>>> Maybe on your arch, but highly doubtful on a 680Mhz mips that >>>>>> isn't even >>>>>> superscalar. >>>>>> >>>>> CPU are fast, memory is slow. >>>>> >>>>>> I'd prefer to leave it in and be able to compile it out, and >>>>>> actually >>>>>> measure the difference. >>>>> You optimize the case where there is no need to optimize (small >>>>> queue) >>>>> >>>>> I can see count bigger than 100000 with 20 concurrent netperf >>>>> >>>>> This makes no sense to have a cache so big. >>>>> >>>>> Or there is a bug in codel >>>> The original reciprocol approximation test code rapidly goes AWOL >>>> after >>>> exceeding 2^8. >>>> >>>> I went looking for butterflies and didn't see any in the scaled >>>> code in >>>> the range 0-100000, >>>> and they would only take flight briefly, so... >>>> >>>> However I have not corrected it for BITS_PER_LONG as per our 4AM >>>> discussion. >>> You should use the exact code in kernel. (using BITS_PER_LONG) >>> >>>> ... >>>> >>>> interval/sqrt(99999)=316229 approx :6250190 19.76475908 >>>> interval/scaled: >>>> 316236 1.00002214 >>>> >>>>> >>> If you read the code , there is no possible overflow, even with very >>> large 'u32 count' >>> >>> anyway the problem is q->count keeps increasing under load. >>> >>> Only when load is stopped for a while, count is reset to 1 >>> >> Stalking butterflies. ( >> http://en.wikipedia.org/wiki/File:Lorenz_attractor_yb.svg ) >> >> I suspected also we would have issues as we hit some natural quantums >> (clock rate/interrupt rate/bql estimator etc) but for all I know it's >> just a plain bug. I need a reboot. Goin to dinner. >> > > If we just compare us to us rather than ns to ns you get chunkier > drops, by a lot... truncate at 10 * *µs *or .1ms seriously going to dinner now > interval/sqrt(370)=5198752 approx :6250190 1.20224815 interval/scaled: > 5198761 1.00000173 > interval/sqrt(371)=5191741 approx :6250190 1.20387169 interval/scaled: > 5191776 1.00000674 > > > secondly adding a fudge factor to the calculation would bring it > closer to inline with an actual sqrt. > > >>> >>> >>> >>> >>> >> > --------------070409000002090502050903 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 05/05/2012 04:09 PM, dave taht wrote:
On 05/05/2012 03:48 PM, dave taht wrote:
On 05/05/2012 03:39 PM, Eric Dumazet wrote:
On Sat, 2012-05-05 at 15:34 -0700, dave taht wrote:
On 05/05/2012 03:09 PM, Eric Dumazet wrote:
On Sat, 2012-05-05 at 15:03 -0700, dave taht wrote:

Maybe on your arch, but highly doubtful on a 680Mhz mips that isn't even
superscalar.

CPU are fast, memory is slow.

I'd prefer to leave it in and be able to compile it out, and actually
measure the difference.
You optimize the case where there is no need to optimize (small queue)

I can see count bigger than 100000 with 20 concurrent netperf

This makes no sense to have a cache so big.

Or there is a bug in codel
The original reciprocol approximation test code rapidly goes AWOL after
exceeding 2^8.

I went looking for butterflies and didn't see any in the scaled code in
the range 0-100000,
and they would only take flight briefly, so...

However I have not corrected it for BITS_PER_LONG as per our 4AM
discussion.
You should use the exact code in kernel. (using BITS_PER_LONG)

...

interval/sqrt(99999)=316229 approx :6250190 19.76475908 interval/scaled:
316236 1.00002214


If you read the code , there is no possible overflow, even with very
large 'u32 count'

anyway the problem is q->count keeps increasing under load.

Only when load is stopped for a while, count is reset to 1

Stalking butterflies. ( http://en.wikipedia.org/wiki/File:Lorenz_attractor_yb.svg )

I suspected also we would have issues as we hit some natural quantums (clock rate/interrupt rate/bql estimator etc) but for all I know it's just a plain bug. I need a reboot. Goin to dinner.


If we just compare us to us rather than ns to ns you get chunkier drops, by a lot...
truncate  at 10 * µs or .1ms

seriously going to dinner now
interval/sqrt(370)=5198752 approx :6250190 1.20224815 interval/scaled: 5198761 1.00000173
interval/sqrt(371)=5191741 approx :6250190 1.20387169 interval/scaled: 5191776 1.00000674


secondly adding a fudge factor to the calculation would bring it closer to inline with an actual sqrt.










--------------070409000002090502050903--