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

Unruh unruh-spam at physics.ubc.ca
Mon Oct 20 02:49:20 UTC 2008


Harlan Stenn <stenn at ntp.org> writes:

>>>> In article <9JPKk.2609$%%2.1111 at edtnps82>, Unruh <unruh-spam at physics.ubc.ca> writes:

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

>Unruh> I would agree that ntpd subsumes this. But using ntpd for the first
>Unruh> is just not a good idea.

>Agreed, which is why http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate
>recommends using SNTP to set the time once quickly, and 'ntpd -gq' to set
>the time once well.

>Unruh> IF the script does the same thing as ntpdate did, then I agree with
>Unruh> you, it will not be noticed. If it does not, there will be screams.

>Well, there will be plenty of time for folks to check it out before I pull
>the trigger.

>Unruh> My only comment would be to please not use sntp as the name for the
>Unruh> clock quick setting program. It will only lead to confusion.

>I still don't see this - SNTP is primarily designed to support "client leaf"
>applications, where the clock is not disciplined.  The 'sntp' program does
>this, and sure looks to me to be an accurate and faithful implementation of
>the SNTP specification.

>Unruh> ntpdate was presumably chosen because it offered a better rdate. To
>Unruh> call it sntp, and then to have an SNTP protocol which does two
>Unruh> incompatible things as well is just guarenteed to confuse everyone.

>I'm still not getting your point.  The 'sntp' program implements the SNTP
>client protocol described in the RFC.  ntpdate was once a good way to set
>the time by querying some number of NTP servers.

>Nobody is talking about taking existing ntpdate code and calling that
>'sntp'.

>And I don't yet see what you mean by "an SNTP protocol which does two
>incompatible things".

It is an server (which other clients can use as a source for time) but one
which only does refclock and is not a client of any other ntp time source, or it is a 
client which, in no case, should ever ever be used as a server. 
Those are two incompatible things.

>Unruh> When someone sells an atomic clock or gps clock with sntp server
>Unruh> service, people will think it is for setting computer times once
>Unruh> quickly and not very accurately. Or think that sntp is a replacement
>Unruh> for ntpd for clients.  or....

>There is no described way to determine if a server is implementing NTP or
>SNTP.  This is a feature.

Agreed.

>There is no way to see if a "client" is an SNTP client or an NTP client.

Agreed.


>The protocol is the same.

>Frankly, I prefer the current nomenclature.  If I see an appliance that
>advertises itself as an SNTP server, I know it will only listen to itself
>for time and will not be able to listen to other servers if a problem is
>detected with its attached refclock.

It does not in general advertise itself as an sntp server as you have just said.


>This is also why I generally prefer to connect to a well-connected S2 NTP
>server instead of an arbitrary S1 NTP server.

Agreed.




More information about the questions mailing list