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.
NetBSD-5 ntpd version would be one of 4.2.6p2, 4.2.6p3
or 4.2.7p98.
I already had a GPS setup as PPS(1) and system offset was
mostly zero +/- a few microseconds.
My experiment was with a watch xtal oscillator divided
down to 1 pps with a pulse width of about 100ms. This was
configured as PPS(2) with 'noselect' and fudge time1 set
so that the initial offset of PPS(2) was within a few
microseconds of PPS(1).
As far as I'm concerned the fudge time1 behaved as I'd
expected and for a short period PPS(2) remained within a
few microseconds of PPS(1) but then drifted with
temperature of the xtal module. Lowest drift rate was a
few 10s of milliseconds/day but come the hotter weather
it was drifting several seconds/day and I decided it
wasn't worth continuing.
David
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
