[ntp:questions] Maximum time2 fudge value for NMEA refclock?
snews at lordynet.org
Mon Jul 19 10:23:54 UTC 2010
David J Taylor wrote:
> "David Lord" <snews at lordynet.org> wrote in message
> news:mhpbh7-ug9.ln1 at p4x2400c.home.lordynet.org...
>> The serial RX data for my Garmin seems to have an offset > 500ms
>> and also vary by at least 20ms. Once PPS synchronises the GPS
>> offset comes more or less in line with PPS but unless that fudge
>> time is used PPS will never be used. That was a known problem
>> that has been fixed but not yet made it to NetBSD I use.
> Strange, I've never seen that problem with the smaller serial offset in
> the GPS-18 LVC, and I have had to add no fudge lines for either:
> GPS-18 LVC on:
> FreeBSD 5.4, type 20 ref.clock, NTP version - as supplied ~2006
> FreeBSD 8.0, type 20 ref.clock, NTP version - as supplied: 4.2.4p5-a (1)
> Windows, type 20 ref.clock, NTP version 4.2.6-o Dec 09
> GPS-18x LVC on:
> Windows-7, type 20 ref.clock, NTP version 4.2.6p2-RC5
> PPS seems to come up more or less at the same time as GPS, even without
> a ~200ms or 500ms+ offset being coded in the config file.
> I wonder what the specification is for the NTP ref.clock drivers, in
> terms of maximum delay of serial data compared to the PPS signal?
When I first tried parallel port PPS I had to google and
unusually it didn't take much searching to find a bug report
and that the issue was fixed in later versions of ntpd.
I think it was  fixed in ntpd-4.2.6
The problem shows when the pps comes from another source,
eg. gps2 and pps0 and the absence of serial DCD to gps2.
The fix by adding a fudge time1 is messy because it depends
on the particular nmea sentences but so long as GPS is fudged
to 30ms or so of the other servers the PPS kicks in ok.
I've not found it possible to compile a more recent ntpd
(4.2.6p1-RC4) on NetBSD as there seems to be many changes
and a lot of magic required. I might download 4.2.4p6-o
and see how the NetBSD version differs.
More information about the questions