[ntp:questions] PPS time1 and reported offset

David Lord snews at lordynet.org
Fri Oct 14 10:55:54 UTC 2011


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.



More information about the questions mailing list