lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ