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?.... > > 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
