Date:	Mon, 01 Jun 2009 16:58:36 -0700
From:	John Stultz <johnstul@...ibm.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	mingo@...hat.com, hpa@...or.com, riel@...hat.com,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	tglx@...utronix.de, linux-tip-commits@...r.kernel.org,
	Miroslav Lichvar <mlichvar@...hat.com>
Subject: Re: [tip:timers/ntp] ntp: adjust SHIFT_PLL to improve NTP
 convergence

On Tue, 2009-06-02 at 01:22 +0200, Ingo Molnar wrote:
> * John Stultz <johnstul@...ibm.com> wrote:
> > On Wed, 2009-05-06 at 09:46 +0000, tip-bot for john stultz wrote:
> > > ntp: adjust SHIFT_PLL to improve NTP convergence
> > > 
> > > The conversion to the ntpv4 reference model
> > > f19923937321244e7dc334767eb4b67e0e3d5c74 ("ntp: convert to the NTP4
> > > reference model") in 2.6.19 added nanosecond resolution the adjtimex
> > > interface, but also changed the "stiffness" of the frequency adjustments,
> > > causing NTP convergence time to greatly increase.
> > > 
> > > SHIFT_PLL, which reduces the stiffness of the freq adjustments, was
> > > designed to be inversely linked to HZ, and the reference value of 4 was
> > > designed for Unix systems using HZ=100.  However Linux's clock steering
> > > code mostly independent of HZ.
> > > 
> > > So this patch reduces the SHIFT_PLL value from 4 to 2, which causes NTPd
> > > behavior to match kernels prior to 2.6.19, greatly reducing convergence
> > > times, and improving close synchronization through environmental thermal
> > > changes.
> > > 
> > > 
> > > [ Impact: tweak NTP algorithm for faster convergence ]
> >
> > 	So I've been speaking with Miroslav (cc'ed) who maintains 
> > the RH ntpd packages, and he's concerned that this patch takes us 
> > out of NTP's expected behavior, which may cause problems when 
> > dealing with non-linux systems using NTP.
> 
> I might be missing something here - but Linux converging faster 
> seems like a genuinely good thing. What non-Linux problem could 
> there be? Linux's convergence is really Linux's private issue. 

Yea. It does seem that way. Miroslav can likely expand on the issue to
help clarify, but as I understand it, the example is if you have a
number of systems that are peers in an NTP network. All of them are
using the same userland NTP daemon. However, if the rate of change that
corrections are applied is different in half of them, you will have
problems getting all the systems to converge together. 

An rough analogy might be creating a an automatic control system to
drive an RC car, and then letting it control a Ferrari. 

Now, that said, I have yet to actually see or hear of any negative
effects of the patch in testing, but I'd  prefer to try to keep to the
NTP spec if we can.

So Miroslav is helping by looking for similar changes we can possibly
make from the userland side. This not only lets us keep the adjtimex()
interface stable while we sort out what options we have, but also, by
trying to tune the NTP knobs in userland instead of kernel space, we are
more likely to get feedback and hopefully constructive solutions by the
NTP gurus who have in the past have maybe been less interested in
Linux's behavior.

So yea, we'll see what comes of it. In the meantime, I know some folks
who will continue to use this patch on their systems because it really
improves things for them. So I'm not abandoning the patch just yet, but
I want to really make sure we're not needlessly changing the kernel
behavior.

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