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

David Woolley david at ex.djwhome.demon.co.uk.invalid
Sun Oct 19 19:05:59 UTC 2008


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


> 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