On 2011-10-13, A C <[email protected]> wrote: > On 10/12/2011 18:30, unruh wrote: >> On 2011-10-12, A C<[email protected]> wrote: >>> On 10/12/2011 13:55, unruh wrote: >>>> On 2011-10-12, A C<[email protected]> wrote: >>>>> 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. >>>> >>>> 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. >>> >>> This is why I'm confused. The fudge factor is supposed to correct for >>> delays on clocks (network clocks, the NMEA clock, etc.) and for all >>> those other clocks, as the clock is disciplined, the offset eventually >>> settles out to zero even though the time1 fudge is non-zero. But the >>> PPS reporting behavior goes against that entirely. My understanding is >>> that PPS is supposed to be the tick of the system clock (with the >>> numbering of the seconds coming from something else) so eventually I >>> wold expect the clock to tick along with the PPS signal and the offset >> >> No, you told the sysem clock NOT to tick along with the PPS signal, but >> to be 3ms early. Thus the PPS comes 3ms late, just as you told it. >> However, the question is whether or not the reporting is inconsistant. >> Eg if you fudge the time in nmea, what does ntpq show? >> >>> to gradually reduce to near zero (ignoring jitter) showing that ntpd has >>> accounted for the delays and now the clock ticks with the right phase >>> such that there is no more offset. >>> >>> As an example, if time1 is set to zero and I let the clock freewheel for >>> a while without ntpd running, it will be skewed from the PPS phase by >>> some amount (in my last test it was about 150 milliseconds). When ntpd >>> starts up, that skew is visible in the offset when I first start ntpd. >>> After some time, the skew gradually disappears and the offset winds its >>> way down to zero thus telling me that the clock is now ticking in tune >>> with PPS. If I know that there's a processing delay in the system that >>> delays the PPS by some amount of time, I should add that to time1 and >>> thus the clock ticks with the appropriate phase shift but I would still >>> expect ntpd to report a zero offset assuming the clock is finally >>> disciplined. >>> >>> Seeing a steady state offset doesn't appear to match the behavior of all >>> the other clock reports from ntpd when a fudge time is added. The other >>> clocks seem to internalize the fudge for the time shift calculations and >>> the offset reported becomes simply the offset of the remote clock versus >>> the local clock after accounting for the delays. It works like this for >>> the NMEA clock, too, where the clock needs a time1 of something like 600 >>> milliseconds because of the transmission and parsing delays. But the >>> offset is shown to be only a few milliseconds because the calculations >>> for disciplining the clock have taken that delay into consideration. >> >> OK, seems to be an inconsistancy. > > Right, exactly. The rest of the clocks take the fudge factor and use it > in the calculations but the reported offset only reports the actual > offset of the system time from the reported time once all the fudge > factors are accounted...except PPS which seems to always report > something that's not zero even after it's settled. > > Now ntpd does seem to use the offset because all the other servers no > longer have a single-sided offset. Seven pool servers were hovering > near 3 ms offsets at all times even after the system had time to settle > down when the PPS had a time1 of zero. Changing PPS to 3 ms erased all > those offsets. Now the pool servers all report offsets centered on zero > instead of centered on 3 ms. But with the PPS driver constantly > reporting an offset I wasn't sure if it was working right at all.
Almost certainly not. I cannot imagine any situation in which a GPS PPS is out by 3ms. It is also weird that the outside pool are all 3ms out, but network delays are more likely than gps 3ms delay. _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
