On Fri, Feb 24, 2012 at 03:53, A C <[email protected]> wrote: > I'd like to try and understand how the PPM of the clock is stepped when > using the ATOM driver and flag3 is set or unset. If you look at the > loopstats file http:/acarver.net/ntpd/loops.20120223 and observe the PPM > column, you'll see that it will sit at one value for a while and then step > to another value and hold again (say from -77.058 to -77.112). This is with > flag3 set (kernel discipline enabled). It never quite settles, it's always > adjusting the number. > > Now, if I clear flag3, the ATOM driver continues to adjust the clock PPM but > it does so in very fine increments of 0.001 and then manages to hold that > for a very long time without jumping around. It may drift up and down by > +/- 0.005 PPM or so depending on the room temperature but it never really > strays from some center value. It also makes the adjustments sooner than > with flag3 set.
You're mistaken about the effect of flag3 1. Your system is using the kernel loop discipline in either case. To change to the daemon loop discipline for comparision, use "disable kernel" in ntp.conf. flag3 1 is enabling kernel "hardpps" where the kernel loop discipline directly follows the PPS signal itself, rather than relying on ntpd to provide offset updates each poll interval. It appears based on your description the "hardpps" support in your kernel timekeeping extensions is not operating as well as when ntpd treats the PPS more or less as just another reference clock. My guess would be the daemon is doing more sophisticated grooming of the raw PPS timestamps, but it's just a guess. If you do try "disable kernel" don't be surprised if you also have to remove flag3 1 -- I'd expect hardpps to be available only when the kernel loop discipline is active. Cheers, Dave Hart _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
