On 10/11/2011 09:04, unruh wrote:
On 2011-10-07, A C<[email protected]> wrote:
I'm trying something out with my local ntpd and its PPS feed from the GPS.
Let us assume that the pulse from the GPS receiver is off from the
master UTC clock tick by about 3 ms due to a variety of delays in the
overall system starting from the satellite and working its way down to
ntpd. (No arguments about how I get to that number, we're just assuming
this is the case).
Well, in that case throw out your system. Something is very very badly
wrong. And how in the world would you know that to be the case anyway?
What do you have that is a better clock than the GPS?
How are you receiving the PPS feed? The kernel PPS? GPSD? shmpps?....
I did say no arguments. Just make the assumption and move on. A GPS is
a very good clock but it is not immune to delay from the time the
signals leave the satellites to the time the signal arrives at ntpd.
No more arguments, I just want to find the answer to the question below
about ntpd's behavior with an offset applied by time1.
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.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
