>________________________________
> From: Harlan Stenn <[email protected]>
>To: Bruce Lilly <[email protected]>
>Cc: [email protected]
>Sent: Wednesday, December 7, 2011 6:56 PM
>Subject: Re: [ntp:questions] ntpdate removal is coming
>
>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
>
>
>
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
