[ntp:questions] "ntpd -q" is slow compared to ntpdate

Harlan Stenn stenn at ntp.org
Sun Oct 19 19:16:04 UTC 2008

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

>> Yawn.

>> 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
"best" choice.

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

The other wanted the time set *well*, with "less" consideration for the
speed with which that was done.

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

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

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.

Harlan Stenn <stenn at ntp.org>
http://ntpforum.isc.org  - be a member!

More information about the questions mailing list