David Woolley <[EMAIL PROTECTED]> writes: >Steve Kostecke wrote:
>> This discussion dates back to August, 2002. >> >> Please see >> http://groups.google.com/group/comp.protocols.time.ntp/msg/3387eda49518407a?dmode=source >> >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 ( uneless it gets its time from an atomic clock). Ie, the promises for sntp seem far stronger than for ntpdate. ntpdate makes no promise to discipline the frequency of a computer's clock. sntp does as far as I can see. The claim is that ntpdate should be retired because a) it is written in a way which is hard to maintain, and support, and b) it is flawed. The first is a perfectly valid concern. The second I would like to know how it is flawed. AFAIK all it does is to set the local clock to the time as determined via ntp packet exchange from some server. it does not set the frequency, it just sets the time. Is there some flaw in the way in which it sets the time? Could I run ntpdate with a reliable server as a source and suddenly discover that my local clock is out by 79 days, or that the frequency has been reset to 1 tick per century? Ie, is there a flaw in what it claims to do? _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
