[ntp:questions] Clock PPM steps

TomK forensic at milwpc.com
Fri Feb 24 14:12:21 UTC 2012


  On 02/24/12 05:41, Dave Hart wrote:
> On Fri, Feb 24, 2012 at 03:53, A C<agcarver+ntp at acarver.net>  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
>
My experience using loop stats logging dictates it is like digital 
voodoo. Yes, it gives you some idea of what's going on, but the current 
offset, and every offset, is a guess. Depending on precision, the 
guesses can be more or less conservative. Small movements in the same 
direction over a longer duration indicate the program is willing to 
assume less risk. Bigger jumps mean the program is willing to assume 
greater risk, which implicates decreased resolution somewhere.


More information about the questions mailing list