David Woolley <[EMAIL PROTECTED]> writes: >Unruh wrote: >> David Woolley <[EMAIL PROTECTED]> writes: >> >>> Unruh wrote: >>>> David Woolley <[EMAIL PROTECTED]> 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). I did read it and am objecting to using the program name sntp to refer to something different from what the rfc says sntp is. >> 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. >> _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
