[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <498A0699.6020103@gmail.com>
Date: Wed, 04 Feb 2009 22:20:25 +0100
From: Jarek Poplawski <jarkao2@...il.com>
To: Denys Fedoryschenko <denys@...p.net.lb>
CC: Stephen Hemminger <shemminger@...ux-foundation.org>,
netdev@...r.kernel.org
Subject: Re: [PATCH] [RESEND] iproute2 : invalid burst/cburst calculation
with hrtimers
Denys Fedoryschenko wrote, On 02/02/2009 07:21 PM:
> Why floating point?
Yes, floating point is not enough. get_hz() == 1000000000 could be
a theoretical resolution, but I guess we don't expect to use this,
even if it were possible. Since high resolution can schedule more
often than 1000HZ, it seems these buffers could be set lower (10x,
100x?), but there should be some reasonable limit.
Jarek P.
> It seems get_hz (and burst in result) just cannot be too low.
> Still seems some code in HTB rely on jiffies, so get_hz() probably just wrong.
>
> Already i'm tried to increase burst/cburst calculation precision, but it will
> fail still with such high get_hz variable.
>
> Ii dont know way to get real HZ variable from userspace.
>
> Here is Martin Devera answer
>> but it really
>> seems as if get_hz() is too high.
>> For 1000Mbps - it is 1MB per 1 ms and assuming HZ=1000, then burst
>> should be about 1MB.
>> But I must admit, I'm not familiar with latest state of HZ in kernel.
>> There was "NO_NZ" effort IIRC, where the HZ granularity can be
>> considerably finer - but still not infinite.
>
>
>
> On Monday 02 February 2009 20:07:42 Stephen Hemminger wrote:
>> On Mon, 2 Feb 2009 19:26:17 +0200
>>
>> Denys Fedoryschenko <denys@...p.net.lb> wrote:
>>> ------------->
>>> iproute2 : invalid burst/cburst calculation with hrtimers
>>>
>>> If hrtimers on, /proc/net/psched shows 4th variable
>>> as 1000000000
>>> Because burst calculated by division rate to this variable,
>>> it will be almost always zero. As result, we will get higher system
>>> load on low rates, and on high rates shaper will not able to process
>>> data. So it is kind of critical bugfix for systems with hrtimers.
>>> It is checked and proved. Core 2 Quad was not able to
>>> shape 200Mbps, and gave only 180-190. It is more safe to set it
>>> to 1000HZ. If user wants, he can set custom "env" HZ variable.
>>>
>>> Signed-off-by: Denys Fedoryschenko <denys@...p.net.lb>
>>> ---
>>>
>>> -------------------------------------------------------
>> I would rather this be converted to floating point.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists