A C wrote:
On 10/13/2011 05:16, David Lord wrote:
NetBSD-5 ntpd version would be one of 4.2.6p2, 4.2.6p3
or 4.2.7p98.
The stable release is 4.2.4 I believe, but I compiled 4.2.6p3 locally
for my own use.
4.2.4 is fairly old (ntp-4.2.4.tar.gz 28-Dec-2006 20:09)
www.ntp.org has Stable: 4.2.6p4 2011/09/23
I already had a GPS setup as PPS(1) and system offset was
mostly zero +/- a few microseconds.
Right, I get the same thing if I don't set time1 at all. When I do set
time1 I get the value of time1 plus or minus some microseconds as an
offset that is always displayed in the peer list. It never settles out
to zero like all the other clock drivers do even when they have a time
offset set on the fudge line.
Looks as if 'fudge time1' isn't working on your system. I've
been using PPSAPI mode rather than kernel PPS so perhaps
time1 correction doesn't have the same effect with kernel PPS.
David
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.
What I'm observing is inconsistent with the operation of the other clock
drivers and the offset that they report. They all report offsets after
time1 is considered during the calculations. But the PPS driver seems
to report the time1 plus whatever other offsets occur.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
