Harlan Stenn <[EMAIL PROTECTED]> writes: >>>> In article <[EMAIL PROTECTED]>, Unruh <[EMAIL PROTECTED]> 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. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
