[ntp:questions] "ntpd -q" is slow compared to ntpdate
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:
>> 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