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

Unruh unruh-spam at physics.ubc.ca
Sun Oct 19 23:38:43 UTC 2008

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

>Unruh wrote:
>> 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.
>> I would think that something called sntp, which as you say "which basically
>> covers anything, other than NTP, using the NTP wire formats" would hold out

>You didn't read what I wrote.  I said that the meaning of sntp in this 
>context was a program that was a minimal SNTP implementation (it 
>performs a single exchange with a single server).

I did read it and am objecting to using the program name sntp to refer to
something different from what the rfc says sntp is. 

>> far more promise of being "almost as good as ntpd" than does a program called ntpdate 
>> (based on rdate) whose only purpose is to use the ntp wire protocol to set the time. 
>> Ie, I do not believe that anyone thinks that ntpdate is as good as ntp (
>> although claims that you could run ntpdate every hour from a cron job as an
>> alternative to ntpd may convey that impression-- but that would also be
>> true of sntp).
>> ntpdate serves a useful purpose, something which ntpd -g -q does not do
>> (because for the purpose of setting the clock in a one-shot manner, ntpd is
>> seriously flawed, especially if the clock is already within 128ms of the
>> correct time). Now, sntp should be equally seriously flawed, since the
>> suggestion in the rfc is that it use the same algorithm for clock setting as ntp uses 
>> I certainly would not overload the name sntp with yet another operating
>> mode. (sntp should not be used as a server, unless sntp is fed by a
>> hardware clock, in which case it can be. Now in addition-- sntp should
>> discipline the phase and frequency of the clock, unless it is used in a
>> oneshot manner when it should discipline only the phase.) I think it is far
>> better to have something called ntpdate to act in a oneshot manner, and be
>> clear that that is all that it is for, than to overload a name  like sntp
>> with all kinds of incompatible operating modes. 

More information about the questions mailing list