Harlan Stenn <st...@ntp.org> wrote in news:ywn98whf205c....@ntp1.isc.org:
>>>> In article <xns9c6c61550389bpqwer...@69.16.185.247>, "nemo_outis" >>>> <a...@xyz.com> writes: > > nemo> No, it means that if you have a program that has been > arbitrarily nemo> diddled so that it WILL NOT ATTEMPT to correct a > frequency error nemo> greater than "x" then, oddly enough, it CAN'T. > > In ntp's case, it means that it will correct up to the limit of > 500ppm. > > nemo> A clock with a frequency deviation is NOT, per se, broken. If > the nemo> deviation, even if it be, say, 5000 ppm, is consistent, > stable and nemo> regular, then the clock could be a superb timekeeper. > > Agreed, and that's what the tickadj program is for - it gives a way to > adjust the base tick value, and this can be use to make sure the clock > frequency is within the range where ntp's 500ppm "vernier" range. > > As for your other coments, I'd like to see a ground-up rewrite (or at > least a refactoring) of the NTP codebase. One of the things I'd like > it to do is to allow different "timing engines" to be used. One would > be the RFC engine. My goal here is to encourage and make it as easy > as possible to test and understand other techniques for accurate > timekeeping. > > H Thank you for your moderate and rational response to my - ahem! - somewhat overheated reaction to "Nero Imhard's" provocative but uninformative reopening of issues that had been largely addressed. I'm a bit embarrassed for having so eagerly taken the bait from an obvious troll. Regards, _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
