[ntp:questions] Garmin GPS18x LVC 5m - Centos 5.5 - Kernel 2.6.18 - gpsd

David J Taylor david-taylor at blueyonder.co.uk.invalid
Tue Dec 28 15:00:26 UTC 2010

"David Lord" <snews at lordynet.org> wrote in message 
news:6utou7-ut8.ln1 at p4x2400c.home.lordynet.org...
> I think it's dependent on the ntpd version as to best
> settings. I was using "fudge time1 0.650"
> and checking stats to make sure NMEA offset remained
> low. That was with ntpd 4.2.4p6-o.

Thanks, David, much appreciated.

As I never needed fudge before, why should I suddenly start to need it? 
And 0.650s sounds rather larger than the measurements would suggest.


(or is the timing from the end of the NMEA, not the beginning?).  As the 
offset showed both +1s, 0 and -1s I'm not 100% convinced that the GPS puck 
was working correctly.  Removing the NMEA and relying just on the type 22 
PPS/ATOM driver seems to have fixed the problem, although it's not my 
preferred solution.

> Other versions of ntpd handle fudge factors in different
> (better?) ways. I'm moving to ntpd 4.2.7p98 and fairly
> sure method for setting up is different.

The PC was running:  4.2.5p181-o, but is now running ntpd 4.2.7p97-o. 
Since I haven't fudged, I haven't compared the methods.  Changing ntpd 
versions didn't seem to affect the problem.

>> As to PPS offset, I can't measure it accurately here but it appears to 
>> be under a millisecond, and perhaps under 100 microseconds.
> On NetBSD I've had periods when rms offset as from
> peer_summary, has remained below  10us for many days.
> Mean offset is usually near 0.000ms. I don't have
> reliable reception so would  expect lower offset with
> a higher aerial position.
> David

I can't compare the /real/ offset, but the values reported by ntpq -p 
typically show well under 7 microseconds, with the largest transients when 
the heating starts in the morning!



More information about the questions mailing list