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