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

Harlan Stenn stenn at ntp.org
Sun Oct 19 21:10:33 UTC 2008


I'm just gonna top post this.

Bill, you are off in the weeds.  The conjectures to not match reality.

"If we had ham, we could have ham and eggs.  If we had eggs."

H
--
>>> In article <GmLKk.2567$%%2.1526 at edtnps82>, Unruh <unruh-spam at physics.ubc.ca> writes:

Unruh> David Woolley <david at ex.djwhome.demon.co.uk.invalid> writes:
>> Unruh wrote:
>>> David Woolley <david at ex.djwhome.demon.co.uk.invalid> writes:

>>> The argument there seems to be not that ntpdate is worse than SNTP, but 
>>> that there is an implied promise that it is almost as good as ntpd.  The 
>>> reason for having SNTP is to have something which has no pretensions of 
>>> being anything other than crude.
>>>  ??? The rfc on sntp seems to say that sntp should be just as good as
>>> ntp in disciplining a local clock, it just should not be used as a
>>> server (

>> The article wasn't talking about SNTP in general (which basically covers
>> anything, other than NTP, using the NTP wire formats), but rather about
>> the minimal SNTP implementation that should be included in the reference
>> implementation package.

Unruh> I would think that something called sntp, which as you say "which
Unruh> basically covers anything, other than NTP, using the NTP wire
Unruh> formats" would hold out far more promise of being "almost as good as
Unruh> ntpd" than does a program called ntpdate (based on rdate) whose only
Unruh> purpose is to use the ntp wire protocol to set the time.

Unruh> Ie, I do not believe that anyone thinks that ntpdate is as good as
Unruh> ntp ( although claims that you could run ntpdate every hour from a
Unruh> cron job as an alternative to ntpd may convey that impression-- but
Unruh> that would also be true of sntp).

Unruh> ntpdate serves a useful purpose, something which ntpd -g -q does not
Unruh> do (because for the purpose of setting the clock in a one-shot
Unruh> manner, ntpd is seriously flawed, especially if the clock is already
Unruh> within 128ms of the correct time). Now, sntp should be equally
Unruh> seriously flawed, since the suggestion in the rfc is that it use the
Unruh> same algorithm for clock setting as ntp uses I certainly would not
Unruh> overload the name sntp with yet another operating mode. (sntp should
Unruh> not be used as a server, unless sntp is fed by a hardware clock, in
Unruh> which case it can be. Now in addition-- sntp should discipline the
Unruh> phase and frequency of the clock, unless it is used in a oneshot
Unruh> manner when it should discipline only the phase.) I think it is far
Unruh> better to have something called ntpdate to act in a oneshot manner,
Unruh> and be clear that that is all that it is for, than to overload a name
Unruh> like sntp with all kinds of incompatible operating modes.
 

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




More information about the questions mailing list