"Maarten Wiltink" <[EMAIL PROTECTED]> writes: >"Unruh" <[EMAIL PROTECTED]> wrote in message >news:[EMAIL PROTECTED] >> "David J Taylor" ><[EMAIL PROTECTED]> writes:
>>> chrony falls at the first hurdle for me - there appears to be no native >>> Windows implementation. >> >> Correct. chrony is not implimented on nearly as many platforms as ntp. >> >> There were plans once upon a time, but life got in Curnoe's way. >> Anyway, I am NOT advocating everyone change to chrony. I am trying to >> understand the clock discipline algorithm. It uses a lot of the special >> features of linux. >And that is _not_ a good thing. To win over the world, as the other David >(Woolley) predicts elsewhere, it would need to be available on Windows at >least. That might actually happen. But to win over some of the people who Sure, it would be nice. It sure will not be me. HOwever if people are convinced that chrony is a better approach ( and that still does need proof, even though the suggestions are there) then I am sure volunteers will be found to port it to Windows. That is after all how NTP got ported. >_really_ matter, it would have to be implemented in a simple, transparent, >and platform-neutral way, and to be driven by clock engineering, not code >writing. The other other David (the original Dave) can *prove* that NTP It is, and this discussion and my experiments are precisely to try to do the clock experiments to see which approach works better. I think Curnoe did put a lot of effort into thinking about how to make it work when he wrote chrony some 10 years ago-- astonishingly it has changed very little and still works extremely well. >will not go unstable under a variety of adverse conditions. Curnoe may >have years of logs showing that chrony keeps offsets lower than ntpd, but >standards laboratories are likely to shrug that off as anecdotal evidence, >not proof. Well, no I do not think he does. I suspect I have the most logs of anyone in the world (www.theory.physics.ubc.ca/chrony/chrony.html-- follow the past logs link) >And anybody who's really serious about timekeeping seems to be playing with >reference clocks on FreeBSD. Err... OK, I do not know why, but... Anyway, I think chrony works on BSD, but could not swear to it. It does work on SunOS and Solaris ( or did) but they have (had?) terrible clock control -- no frequency changes-- at least as implimented in chrony. chrony is old code, but it works very well. Its whole design goal is to reduce errors in the offset. It is really hard to go unstable if that is the goal, but it is possible, especially if you are interested in very long intervals between clock queries. It is at that point that you want to make sure that your model of the frequency drift and your estimation of the frequencies is the best possible. I do worry a bit about chrony in that situation, but have no reasons for that worry. The very worst case is if the system runs for a while on very short poll intervals, and then suddenly has very log poll intervals. The short period estimation of the drift is not a good estimator of the long period drift. But I suspect that NTP would have problemsi in that situation as well. _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions