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 _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
