[ntp:questions] ntpdate removal is coming

Bruce Lilly bruce.lilly at gmail.com
Thu Dec 8 21:26:28 UTC 2011


On Thu, 08 Dec 2011 20:14:28 +0000, Harlan Stenn wrote:

> Bruce wrote:
>> On Wed, 07 Dec 2011 23:56:08 +0000, Harlan Stenn wrote:
> 
>> Short
>> of that, getting close to the right offset before starting ntpd means:
>> 1) processes that depend on reasonably-close time synchronization
>>    (rsync, etc.) can proceed
> 
> Again, the BCP I described earlier addresses this too...
> 
>> 2) ntpd converges to a stable point that much faster (i.e. it has
>>    less of an initial offset to remove)
> 
> At the moment, the worst case for this is an offset that is just under
> 128ms, which will take under 5 minutes to apply at the standard slew
> rate of 500ppm.  (64ms will take about 2.5 minutes' time to apply, etc.)

Those times apply *after* enough samples have been gathered for an
offset estimate, which happens *after* a system peer has been selected.
That can take many minutes.  With ntp-wait, the boot sequence would
be effectively stalled for the duration.

>> I use sntp (rather than ntpd -q or ntp-wait) because it's much faster
>> than the alternatives (life is too short for thumb-twiddling).
> 
> And you might still get a backwards step in this case.

Not a problem during startup, before anything that needs synchronization
is running.

> The bottom line is that you have not communicated any information to me
> that indicates you have a *need* to set the time before NTP starts.

"Need" is a strong term; it's true that the world as we know it won't
come to an abrupt end if booting is stalled for ten minutes, but it is
rather inconvenient.  In any event, my initial response was to point
out two issues:
1. your reference to "a good drift file" presumes that all systems have
   a frequency offset which is stable across a reboot; that is an
   invalid assumption for most machines that I have in service here.
   Please bear in mind the fact that many systems do not have a stable
   frequency offset around a reboot and therefore cannot make practical
   use of a drift file at system startup (stop/restart of ntpd while
   the system is running is of course another matter).
2. your estimate of "fully sync'd in 11 seconds' time" seemed overly
   optimistic (and still does, even with minimum polling times and
   maximum slew rate).

To which I would add that there are some configuration options (e.g.
xleave) which ameliorate some issues during steady-state operation but
which seem to make startup (system peer selection in particular) take
much longer after a reboot.



More information about the questions mailing list