[gpsd-dev] Direct GPS support in ntpd makes me nervous

[Eric S. Raymond]

Andy Walls <address@hidden>:
> Check the list of reference clock drivers at the bottom of this page:
> 
> http://www.eecis.udel.edu/~mills/ntp/html/refclock.html
> 
> Type 20 is Generic NMEA, but there are others (Jupiter, Oncore,
> Palisade, etc.).

Heads up, Harlan. You need to hear this.

Learning that there is direct GPS support in ntpd makes me nervous.
I recommend you take a good hard look at *removing* it.

Getting GPS sentence parsing right is much harder than it looks, and
has lots of unobvious failure modes. The problem isn't algorithmic
difficulty, it's background issues like NMEA being very weakly
specified. A driver based on one or a few NMEA devices is likely to
embody regularity assumptions that will be false on many others.

Things like varying sentence orders in fix reports and the
presence/absence of ZDA are likely to bite you in the ass.  And I have
to tell you that aggregating a full timestamp out of the mess has
been one of the *most* trouble-prone parts. (That and sky views have
been the two worst pain points.)

GPSD specializes in this job and has the best test suite in existence.
Even so it took us *years* of effort to get this right.  I trust our
code, but I don't trust anybody else's - because you can't beat this
problem just by being smart and careful.  It takes lots of ugly
experience and having your nose rubbed in the take from fifty
different kinds of idiosyncratic and semi-broken GPSes.

We've had that experience. Nobody else has. I therefore strongly
recommend that, for the sake of ntpd's future defect rate and
robustness under field conditions, you exit this piece of the
hardware-management problem and leave it to GPSD.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>