[ntp:questions] PPS time1 and reported offset

unruh unruh at physics.ubc.ca
Wed Oct 12 20:55:31 UTC 2011


On 2011-10-12, A C <agcarver+ntp at acarver.net> wrote:
> On 10/12/2011 10:25, Dave Hart wrote:
>> On Fri, Oct 7, 2011 at 05:15, A C<agcarver+ntp at acarver.net>  wrote:
>>> If a server (or the GPS NMEA data) is off from the master clock by some
>>> amount, you correct for the delay with time1 and, according to ntpq -p, the
>>> offsets eventually trend towards zero.  However, that's not what I see if I
>>> set time1 to 0.003 on the PPS input. What I see there is a constant 3.000
>>> reading in the offset column (plus or minus a bit of drift/jitter).   It
>>> never seems to wind down to zero like a server or the NMEA reference clock
>>> as the clock is disciplined.
>>>
>>> Is this normal behavior for the PPS input or should I expect what I normally
>>> see on other servers?  I would have expected that the offset is some amount
>>> but eventually comes down to zero or near zero as the clock is disciplined
>>> over the course of ntpd's operation.
>>
>> What version of ntpd are you testing?  In recent versions, the PPSAPI
>> support in the atom driver and the NMEA driver is implemented using
>> the same common code.  Given you made it clear in a subsequent message
>> you're talking about the atom (PPS) driver here, and noting a
>> difference in PPS behavior compared to with the NMEA driver, we need
>> to be clear about which version of ntpd you're using.
>>
>> Cheers,
>> Dave Hart
>
>
> You are correct, I'm using only the PPS driver (plus Internet pool 
> servers) and it's on version 4.2.6p3.
>
>
>
> Here's a slice of the output from ntpq -pn:
>>      remote           refid      st t when poll reach   delay   offset  jitter
>> ==============================================================================
>> o127.127.22.1    .PPS.            0 l    5   16  377    0.000    3.009   0.061
>
> Note the offset shown is 3 ms (time1 is 0.003) and it varies slightly by 
> a few tens of microseconds based on the jitter in the system.  Kernel 
> PPS is implemented in this case.  What I thought was normal behavior was 
> for that offset to slowly move towards zero as the clock stabilized and 
> ticked in unison with the PPS signal.  But the offset for the PPS never 
> goes away, it just stays near whatever time1 is set for.  If I set time1 
> for say 10ms, the peer list will show a 10 ms offset that doesn't go away.

But if time1 is 3 ms, then your system IS out by 3ms. Ie, the time on
your system clock is 3ms out from the time on the PPS pulse. So your
question seems to be "why is ntpq reporting the actual system time of
the PPS pulse rather than the fudged time?" Is, 3ms IS the offset
between the PPS pulse and your system time. 




More information about the questions mailing list