[ntp:questions] ntpdate removal is coming

Steve Kostecke kostecke at ntp.org
Fri Dec 9 14:12:12 UTC 2011


On 2011-12-08, Bruce Lilly <bruce.lilly at gmail.com> wrote:

> 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...

There is nothing common about the use of ntp-wait. So I don't understand
why it is being referred to as a "BCP".

>>> 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.)

functional equivalentfunctional equivalent  

> 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.

There is no need to use ntp-wait.

Use sntp.

Use a seperate 'ntpd -gq' invocation.

>>> 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).

'ntpd -gq' exits after either stepping the clock or initiaing a slew.

I've observed this happen in as little as 11 seconds.

>> 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).

Why is it acceptable to initially set the clock to approximately the
correct time with ntpdate but not with ntpd?

You're so busy looking at the trees that you don't see the forest.

> 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).

The 11 second figure applies to the initial setting of the clock with
'ntpd -gq' (which is analogous to the use of ntpdate for the same
purpose) and not to disciplining the clock to maximum stability.

-- 
Steve Kostecke <kostecke at ntp.org>
NTP Public Services Project - http://support.ntp.org/



More information about the questions mailing list