Re: [tip:timers/ntp] ntp: adjust SHIFT_PLL to improve NTPconvergence

[Mr. James W. Laferriere]

	Hello All ,

On Mon, 1 Jun 2009, Ray Lee wrote:
> On Mon, Jun 1, 2009 at 4:58 PM, John Stultz <johnstul@xxxxxxxxxx> wrote:
> > On Tue, 2009-06-02 at 01:22 +0200, Ingo Molnar wrote:
> > > * John Stultz <johnstul@xxxxxxxxxx> 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.
>
> Your point is clear, however -- reasonably speaking --  how many
> instances will there be out there of networks of peers partially
> upgraded versus lone systems slowly or never converging off of
> masters?
	A site with three or four differant system types ,  ie: sparc running 
sloaris ,  pc running openbsd ,  Dec(hp) running VMS ,  Dec(hp) Alpha running 
Linux , ...
	This moving the Hardware Arch & OS differencews is sometimes done to 
limit hacks & software glicthes by NOT using the same hardware arch or OS .

> By my naive understanding, the latter would strongly outnumber the former.
	You'd be VERY unhappily suprised .

		Hth ,  JimL
--
+------------------------------------------------------------------+
| James   W.   Laferriere | System    Techniques | Give me VMS     |
| Network&System Engineer | 2133    McCullam Ave |  Give me Linux  |
| babydr@xxxxxxxxxxxxxxxx | Fairbanks, AK. 99701 |   only  on  AXP |
+------------------------------------------------------------------+