Unruh wrote: > Just an update: I started chrony with a 60ms offset. It had the right drift > file. It took about 1 min ( having collected about 4 samples from the > servers at minpoll 4) to drive the offset down to about 100 usec (Yes, a > 1000 fold improvement in about 50 sec.) Ie, the time constant for > correction of offset errors is enough time to collect enough samples to > determine that the offset really is statistically way off. >
Is that supposed to be impressive? One of the design constraints of NTP is to limit the clock frequency change during offset adjustments to 500ppm to prevent NTP network instabilities. If the offset was amortized over the 50secs you stated, then that is a slew rate of 1200 ppm. If this happened entirely at the end of the 4 samples, then it sounds simply like a step to me. By that reasoning, ntpdate far outperforms chrony. I presume that chrony cannot behave as a server and only does clients right? > I also started chrony without a drift file. In this case it took about 5 > min to get a frequency within 10% of the long term stable frequency and > that "error" disappeared within 1/2 hour. > I don't know about the version of ntp you are running, but recent versions have a bug in the initial frequency calculations which has since been fixed, but not released (ahem. Harlan?). Brian Utterback _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
