[ntp:questions] "ntpd -q" is slow compared to ntpdate
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
>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
>And I don't yet see what you mean by "an SNTP protocol which does two
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.
>There is no way to see if a "client" is an SNTP client or an NTP client.
>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.
More information about the questions