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]
Message-Id: <1245261342.6067.102.camel@jstultz-laptop>
Date:	Wed, 17 Jun 2009 10:55:42 -0700
From:	John Stultz <johnstul@...ibm.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Miroslav Lichvar <mlichvar@...hat.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, 2009-06-17 at 19:26 +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)

I believe he means the TSC calibration error issue, where every boot the
TSC calibration varies by 30-80ppm. This makes it hard for systems to
stay in NTP sync after a reboot, because ntpd has to search for a new
freq (and the SHIFT_PLL & time_constant values control how fast that
happens).

While the TSC calibration is an issue, there is also the fact that NTP's
slow convergence model (which is "by design", for good or bad) doesn't
seem to handle thermal environment changes quickly enough to keep close
sync.

Now, weather we fix the change by tweaking ntpd or the kernel, I still
think is a question that we've not answered well. Even though I'm of the
opinion something needs to change, I'm not yet convinced of which side
is the right side to fix. And that is why I requested we hold off on
merging the SHIFT_PLL patch.

And really, if you look at Miroslav's patch, which is mathematically
equivalent to the SHIFT_PLL change, all we're doing is decreasing what
ntpd gave as the time_constant us by two. So the question is, why is
that fix best done in the kernel, instead of making ntpd reduce what it
passes in to the kernel?

thanks
-john

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