Bruce wrote:
> On Wed, 07 Dec 2011 07:30:12 +0000, Harlan Stenn wrote:
>
> > I'm saying I'm not aware of good reasons to set the clock before
> > starting ntpd at system startup.
> [...]
> > With a good drift file and a proper ntp.conf file, ntpd will have the
> > clock fully sync'd in about 11 seconds' time.
>
> Of 18 computers here currently running ntpd, 11 do not have stable
> frequency offset across a reboot (i.e. a drift file is not useful at
> system startup for those machines). The remaining 7 machines do have
> stable frequency offset across a reboot except in the case of a kernel
> update, which does sometimes cause a change in frequency offset even in
> those machines. Four of the machines are not normally on-line; they are
> running as a testbed for a distribution update which is being rolled out,
> and one of those four is one of the ones with a stable frequency offset
> (so the normal numbers are 14 computers running ntpd, 8 of which do not
> have a stable frequency offset across a reboot). Motherboard/BIOS
> design seems to have the biggest impact on frequency offset stability
> across a reboot (four of the seven machines with stable frequency
> offsets are of a single motherboard design). Ntpd version is a
> modified 4.2.6p4.
I've beeh chatting with Dave Hart about this.
Just like the use-case for ntpdate has evolved over time (set the time
ASAP v. set the time well), the use-case for "wait until the clock is
sync'd" has evolved ("sync" means different things to different folks).
We're gonna talk more about this, as from my POV "sync" used to mean
"state 4", which now means EVNT_SYNC, and when "state 4" no longer meant
EVENT_SYNC we changed how we looked for this and at that time the
indicator we chose to use was "leap != 11". This is clearly not
sufficient, so we're digging deeper.
> I do run sntp to set the clock before starting ntpd (so I don't need
> ntpdate). Setting the clock this way at least gets the time offset
> in the ballpark before ntpd starts.
OK, and exactly why do you need "the time offset in the ballpark before
ntpd starts"?
> Also, I have not seen machines "fully sync'd" in anywhere near as
> quickly as 11 seconds, but my interpretation of "fully sync'd" may
> differ from yours; I consider a machine "fully sync'd" only
> when time offset, frequency offset, and jitter (as reported in
> loopstats) have all stabilized, which may take a few hours.
Yes, this is what we're gonna talk more about.
I believe we're gonna have both "ntp-wait" and "ntpd --wait-sync" behave
as before, but we will also have a way to say "sync means XXX" as well,
because some folks are fine with sync meaning "We do not expect the
clock to step backwards, but we're still homing in on the steady-state"
and others want this steady-state. There may be more choices...
H
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
