Terje, Terje Mathisen wrote: > Martin Burnicki wrote: >> Then ntpd starts to correct the initial offset properly in less than 300 >> seconds. This looks like it was going to converge properly. However, >> unfortunately at a 10 ms offset the filter algorithm seems to switch and >> the following correction is still very poor compared to the initial >> correction. > > Martin, the 10 ms behavior is pretty much a given, since the OS clock > works at the same 10 ms resolution!
This is not quite true. At least in Windows 2000 the clock tick interval seems to depend on the CPU speed or whatever. I've seen nominal tick reload values of 100144 (10.0144 ms tick interval) on older systems, whereas the same version of the OS installed on a system with more CPU power had 156250, resulting in a timer tick interval of 15.6250 ms. Except some very old machines I have no more machines around here which use the 10 ms tick interval. > The realtime thread hack to interpolate between OS ticks does help, but > NTPD still needs a lot of statistical data to be able to settle down at > offset values well below the OS tick! >From what I've seen the interpolation thread works very well to increase the resolution of the system clock beyond the 10 or 15 millisecond limit, at least to 1 ms or so. So the ntpd filters should not be aware of a 10 ms limit. And we also see that ntpd can discipline the system time down to the 1 or 2 ms level. However, this takes _very_ long for recent implementations. Older implementations achieved this much faster, though this also had not been optimal. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
