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:	Thu, 18 Jun 2009 14:13:20 +0200
From:	Miroslav Lichvar <mlichvar@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	John Stultz <johnstul@...ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [GIT pull] ntp updates for 2.6.31

On Wed, Jun 17, 2009 at 07:26:01PM +0200, Ingo Molnar wrote:
> * Miroslav Lichvar <mlichvar@...hat.com> wrote:
> 
> > Still, I'd really like to see the original behavior restored. Most 
> > of the users complaining about slow convergence are probably just 
> > hitting the calibration problem, which needs to be fixed by other 
> > means than making PLL faster. Also, users of other systems seem to 
> > be happy with their slow convergence. At least that's the 
> > impression I have from NTP lists.
> 
> Wouldnt the goal be to calibrate as fast as possible? (Without any 
> bad oscillation)

Not really. It depends on how noisy is the input signal. On an idle
LAN the jitter is just few microseconds, but over internet it easily
reaches miliseconds. Over a certain point faster PLL will just make
things worse.

PLL is mainly about handling the signal noise, frequency adjusting is
secondary. When the noise is very low or the update interval is long
enough, the frequency variations caused by temperature changes will
dominate the signal noise and this is where FLL should kick in.

The PLL/FLL switching is controlled by update interval. Ideally it
would be adaptive, but NTP is not that sophisticated. By default, FLL
is enabled when the interval is longer than 2048 seconds. This is of
course not the optimal value for all systems.

Unfortunately in kernel it can be configured only to 2048 or 256 and
NTP never uses the shorter one. The NTP daemon has its own loop which
can be used instead and it allows to use arbitrary values though.

-- 
Miroslav Lichvar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ