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. > > >>> >>> >>> >>> >>> >> >