Brian Utterback <[EMAIL PROTECTED]> writes: >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 NO it is NOT a step. It is done via a fast slew by a change in the tick size, which can be 10% (ie +-100000PPM) The clock always runs forward. It does not step. It may seem like a step from the point of the coarse sampling done by chrony or ntp, but if you ran a PPS clock and looked at the time returned by gettimeofday, it would be continuous and positive, just like ntp. When the NPT offset changes by 100ms between samples spaced at 500 sec apart, did it do that by stepping? No it did it by increasing the frequency by 200PPM. Chrony behaves the same way, only it uses the ticksize as well as the frequency to produce fast slews to get rid of the offsets, and it does not go unstable that I have ever seen. >outperforms chrony. I presume that chrony cannot behave as a server and >only does clients right? Chrony is also a server. The key detraction for me is that it cannot use hardware clocks. It also does not act as a multicast/broadcast server which may be a detraction for others and does not do leap seconds. On the other hand with its rapid response it will correct the leapsecond within less than an hour. Anyway, the issue here is the clock disciplining routine, not a comparison of the chronyd program with the ntp implimentation. I am arguing that chrony's clock discipline routine keeps the hardware clock much closer to the real time (in the real world) and reacts to real world changes much faster than does the NTP discipline routine. And chrony is just as stable it seems as NTP is. The offset fluctuations are better than NTP's are. The key question is how close to the real time is the time that the system clock delivers. Chrony is closer by factors of at least 2 and probably if run at high priority as my ntp is, much better than that. In particular if there are glitches in the clock drift rate, chrony reacts much faster, and keeps the time much much closer to the true time. Instability would produce worse behaviour not better. >> 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?). The initial horrible transient was under 4.2.0. After this round I will try an initial transient test with 4.2.4. But the transient behaviour I am describing in the previous post is during the normal running of NTP. It is not an initial transient. It is the response of the system to a real world drift rate glitch. It is after NTP has been running for 5 days and the hardware clock on the machine suffered a frequency glitch. I have no idea what is causing those frequency glitches-- the clock suddenly canges it drift rate by .2 to 2 PPM. I have seen this both with a chrony controlled clock and an NTP controlled clock. It is just that the NTP response is not good. _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
