On 10/12/2011 10:25, Dave Hart wrote:
On Fri, Oct 7, 2011 at 05:15, A C<[email protected]> 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.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
