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 E8E1220061E for ; Sat, 5 May 2012 16:09:23 -0700 (PDT) Received: by dadz8 with SMTP id z8so1811381dad.7 for ; Sat, 05 May 2012 16:09:23 -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=Nhc7qmIFHKt9Nk+/YBKQcY1DFMnOU1XnF2xFzDuk37M=; b=JDmTbv5EcSpP/moGgj24Gd1S0O1CjnCCCcqj1VE14r42v7NJx2fD2H8ifSBBEDO9Jb dqUtiUee9brQ7WjoI9pvdult20L9RC8bo/fP51DSDb00wm5N8jcgwTi/uNFsxpmfM0/g 2YVYW1ACzTKjnBPCBVh/Mumgt5yWugZgwDqU3MQzQiJXLIqRptmYF6jdKB73C2lwz6PP y48p7Wh3LUpLAsAJXjrlO2dnpXnupUKqBpb0fv8sK4F6r7utbo/hOQsWGJr8gw9l4AXm kdxo75Y821Kt3mwM01koPcOJr8RGOcqpiwmsbMmmaukOMG00nt4ecTQxW3+36tTaQ4dE NycQ== Received: by 10.68.204.165 with SMTP id kz5mr2823711pbc.11.1336259363614; Sat, 05 May 2012 16:09:23 -0700 (PDT) Received: from ?IPv6:2001:4f8:3:203::c001? ([2001:4f8:3:203::c001]) by mx.google.com with ESMTPS id vl3sm13070559pbc.44.2012.05.05.16.09.22 (version=SSLv3 cipher=OTHER); Sat, 05 May 2012 16:09:22 -0700 (PDT) Message-ID: <4FA5B320.8050207@gmail.com> Date: Sat, 05 May 2012 16:09:20 -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> In-Reply-To: <4FA5AE25.1080506@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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:09:24 -0000 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... 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. >> >> >> >> >> >