[ntp:questions] [ntp:hackers] ntpdate removal is coming
stenn at ntp.org
Sun Jul 17 22:29:36 UTC 2011
> On Jul 17, 2011, at 1:57 PM, Harlan Stenn wrote:
>> Dave Hart wrote:
>>> 2) One-shot clock synchronization, such as before starting
>>> step-phobic daemons. In this role, there are a plethora of
>>> alternatives, which I will cover below.
>> Just to be clear, there *used* to be some reasons to set the clock
>> before starting ntpd. In general, there is no need to do this
>> anymore and I have not heard any good reasons it should still be
>> If anybody knows of any *good* reasons to set the clock before
>> starting ntpd, please speak up.
> ntpdate was used to get sub-second synchronization at the cost of
> about a second of delay in startup.
But you were not getting *synchronization*, you were just getting the
time set. Synchronization requires knowledge of frequency correction,
> ntpd would take a lot longer to do this, and would have problems with
Right, and the "steps" problem was resolved Years ago, as I recall.
Originally, ntpd and ntpdate used the same algorithms for initial clock
selection, so there goes the "how long it took" argument.
> Most daemons hate it when time jumps too much, so this was a good
OK, and this is before we had sntp, ntpd -gq, or ntp-wait.
> Does ntpd still dial in the frequency error before doing the phase
> shift that's patently obvious at startup?
I'm not exactly sure what you mean.
> If so, then there's still a need for ntpdate.
Sorry, since I don't know what you meant above I don't see your
But more below...
> ntpd would also used to start asynchronously, meaning that it was a
> crap shoot if your daemons would see a a big time-step or not after
> they started.
That's why we have ntp-wait, and the option Dave Hart described.
> If these problems have been corrected completely, then maybe ntpdate can
> be killed. Otherwise, there's still a need for it.
I believe the problems you have described are in the past. ntpdate
was/is broken, and will not be fixed. Our new tools seem to offer
solutions for the identified use cases. I understand that some folks
will want to keep something called ntpdate around for their own reasons.
Please see http://support.ntp.org/Dev/DeprecatingNtpdate for more
discussion about all of this.
Also see http://support.ntp.org/Support/StartingNTP4 .
To summarize a bit, if you care enough to run NTP, you either care a
Little, in which case you can just periodically run sntp from cron, or
you care More, in which case you run ntpd.
If you care enough to run ntpd, then you can either run it somewhere in
between "badly" or "well". For the sake of this discussion, I'm gonna
shoot for the "well" case because that seems to make the most sense.
There are plenty of ways to run ntpd badly (or at least not well).
So, for this situation:
1) There is still no demonstrated need to set the clock before starting
If you care about stable time, ntpd will need some time to make sure
things are running smoothly. Start ntpd as early as possible in the
boot sequence. If you have time-sensitive processes, start everything
else first, then run ntp-wait and then fire off your time-sensitive
If you *insist* on setting the clock before starting ntpd, that's fine,
but I submit this merely adds a bit of delay to your startup time and
does nothing else of *real value*.
If you follow our documented BCP, you'll be using 'iburst' and you'll
(most always) have a good drift file. Starting ntpd from here (with -gN
if you care a lot, or -g if you care a bit less) means your clock will
be stable (correct time with no reason to expect a 'step') in about 11
2) As time passed, there became 2 groups of folks using ntpdate, those
who wanted it to set the time well and those who wanted the time set
Ntpdate has been losing the ability to set the time well, but ntpd -gq
can set the time once, well.
sntp does a better job of setting the time once quickly.
ntpd can set the time well and keep the time right.
We will provide an ntpdate script, and somewhere, somebody is going to
have to decide if the "default" case is to set the time well, or set the
time quickly. We will certainly provide the mechanism(s) to handle
either of these cases, and we *can* provide a default policy (fast,
well, or "error - choose 'fast' or 'well').
My point here is that we had and "old way" and we have a "new way".
They are different. The new way seems to give us all of the
functionality we have wanted, with much better control. To take
advantage of this, use it properly. Do not expect to get good results
from "what we used to do".
More information about the questions