[ntp:questions] "ntpd -q" is slow compared to ntpdate
unruh-spam at physics.ubc.ca
Sun Oct 19 23:50:29 UTC 2008
Harlan Stenn <stenn at ntp.org> writes:
>>>> In article <j4KKk.2556$%%2.1041 at edtnps82>, Unruh <unruh-spam at physics.ubc.ca> writes:
>Unruh> Harlan Stenn <stenn at ntp.org> writes:
>>>>>> In article <GQoKk.2334$%%2.337 at edtnps82>, Unruh
>>>>>> <unruh-spam at physics.ubc.ca> writes:
>Unruh> But with ntpdate, the server is under your control. So this is hardly
>Unruh> something I would call "broken". Harlan insists that it is broken--
>Unruh> mentioned it twice-- but never said how and why it is broken. What he
>Unruh> calls broken may be a feature other people never use.
>>> As a troll attempt, that was pretty lame. And there are enough trolls.
>Unruh> It was NOT a troll attempt. It was an attempt to learn what you
>Unruh> consider the flaws in ntpdate are, so that users can make up their
>Unruh> own mind whether or not to use it. I understand that there is a long
>Unruh> long long running desire to get rid of it ( which has apparently
>Unruh> failed), but I do not understand what the flaws are.
>I do not choose to investigate the archives to find even a portion of the
>"evidence". For folks who have "been around", I believe it is just accepted
>that we remember that ntpdate has serious flaws and nobody wants to fix it,
>especially now that ntpd has most of the needed functionality and sntp has
>the rest. The only thing left before we "pull the trigger" is to finish
>sntp and perhaps write a script called ntpdate to drop in for folks who just
>don't care to make a more conscious choice.
>At one time, ntpd and ntpdate contained duplicate code. If ntpdate was
>given a single hostname, it sent the packet, got the response, and set the
>time. If it was given more than one hostname it sent the request to each
>host and originally ran the same algorithms as ntpd to set the time from the
I assume you mean it ran the host selection algorithm, without the "filter"
or the frequency discipline algorithm.
>Over the years, many bugs were found and many improvements were made to
>the selection algorithms and even the time-setting code in ntpd that were
>*not* made to ntpdate.
>It also became clear that there were at least two populations who used
>ntpdate, and they had conflicting goals.
>One wanted the time set ASAP, with "less" consideration for the quality of
>The other wanted the time set *well*, with "less" consideration for the
>speed with which that was done.
I would agree that ntpd subsumes this. But using ntpd for the first is just
not a good idea.
>Each of these groups wanted to do this before ntpd, because in most cases
>they wanted to start ntpd after the time was set (because we didn't have
>enough knobs to offer the variety of policy choices users wanted in ntpd
>The best solution to this mess was to deprecate ntpdate, once there was a
>way to provide all of the intended *and assumed* functionality of ntpdate by
>some other way.
>The first set was removing the need to set the time with ntpdate before
>starting ntpd. The solution to this problem is -g, and perhaps calling
>ntp-wait (which actually implemented a missing feature that had been needed
>The next step was to decide which was more important for local policy,
>setting the time, once, well (ntpd -q) or setting the time, once, quickly
>If people think the current ntpdate is working well I would bet (and I
>believe I'd win the bet) that they are not getting the behavior they think
>they are getting, and they are oblivious to the (occasional?) problems they
>>> Believe me or not, your choice.
>Unruh> I thought were were talking about facts, not beliefs.
>It has been my experience that any "link" between facts->beliefs is heavily
>tainted with ... hallucination. But things mostly work out anyway. Mostly.
>As Samuel Johnson said: Subsequence does not imply consequence.
>>> I recommend searching the archives - the status of ntpdate is pretty old
>>> news, and predates the support twiki (as I recall), and the decision to
>>> deprecate ntpdate may even predate our use of bugzilla.
>Unruh> Yes, it is old, and has apparently failed to have any effect. ntpdate
>Unruh> is still there, and thousands still rely on it.
>There will be a script called "ntpdate" for those folks who want to keep
>running a program by that name.
>But I don't see how your point relates to the underlying issue.
>I think the biggest reason ntpdate has stuck around is we have not forced
>the issue. When we remove the old code and include a new script, I bet most
>folks will simply not notice.
IF the script does the same thing as ntpdate did, then I agree with you, it
will not be noticed. If it does not, there will be screams.
>The ones who *do* notice will be the ones who (think they) care enough to
>make a choice and override whatever behavior they do not like.
>>> I'm probably done with this thread.
>Unruh> Ok, that is of course your choice. I would still like to know what
>Unruh> the flaws are.
>I'm not sure I have answered to your satisfaction, but I hope this is at
>least a sufficient step in the right direction.
Yes, thank you.
My only comment would be to please not use sntp as the name for the clock
quick setting program. It will only lead to confusion.
ntpdate was presumably chosen because it offered a better rdate. To call it
sntp, and then to have an SNTP protocol which does two incompatible things
as well is just guarenteed to confuse everyone.
When someone sells an atomic clock or gps clock with sntp server service,
people will think it is for setting computer times once quickly and not
very accurately. Or think that sntp is a replacement for ntpd for clients.
More information about the questions