[ntp:questions] "ntpd -q" is slow compared to ntpdate
stenn at ntp.org
Mon Oct 20 02:18:46 UTC 2008
>>> 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
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.
This is also why I generally prefer to connect to a well-connected S2 NTP
server instead of an arbitrary S1 NTP server.
Harlan Stenn <stenn at ntp.org>
http://ntpforum.isc.org - be a member!
More information about the questions