Re: [Codel] [PATCH v5] pkt_sched: codel: Controlled Delay AQM

[dave taht <dave.taht@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2457 bytes --]

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 <http://en.wikipedia.org/wiki/Mu_%28letter%29> *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.
>
>
>>>
>>>
>>>
>>>
>>>
>>
>


[-- Attachment #2: Type: text/html, Size: 4743 bytes --]