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

[Eric S. Raymond]

Gary E. Miller <address@hidden>:
> > Learning that there is direct GPS support in ntpd makes me nervous.
> > I recommend you take a good hard look at *removing* it.
> 
> I think this is a tad harsh.

Alas, I think you're a tad too sanguine.  Thinking about it, I guess you
haven't been as exposed to the vicissitudes of NMEA as I have.  Maybe
nobody else has, either. Lucky them. :-(

>                        ntpd assumes the daemon is network
> connected and so has a number of other sources to get data like the
> current century and the leap seconds.  It also has no need for position,
> velocity, error estimates, sky view, etc.

That is true, and it's not what I'm worried about.

>                                         All ntpd really needs is the
> top of the second from the PPS.  Then it takes that data from the
> multiple sources, applies voting rules and comes up with a best guess.

No, what it needs is PPS *together with an in-stream timestamp*.  Does
the reconciliation algorithms no good to know top of second if the 
associated information on which second it's the top of is missing
or garbled.

> If it misses some GPS time thing then the voting will ignore the GPS
> data until later it seems valid.

I'm actually less worried about missing time than garbled time.  The worst
case, from the point of view of the reconciliation algoritms, is time
that is garbled but looks plausible.  Like, off by one second.  And
there are very plausible ways for that to happen if your NMEA driver
makes assumptions that don't match reality.  

Look at the code in driver_nmea0183.c just after this comment:

/**************************************************************************
 *
 * Scary timestamp fudging begins here
 *
 * Four sentences, GGA and GLL and RMC and ZDA, contain timestamps.
 * GGA/GLL/RMC timestamps look like hhmmss.ss, with the trailing .ss
 * part optional.  RMC has a date field, in the format ddmmyy.  ZDA
 * has separate fields for day/month/year, with a 4-digit year.  This
 * means that for RMC we must supply a century and for GGA and GLL we
 * must supply a century, year, and day.  We get the missing data from
 * a previous RMC or ZDA; century in RMC is supplied from the daemon's
 * context (initialized at startup time) if there has been no previous
 * ZDA.
 *
 **************************************************************************/

If the hackery that follows doesn't make you nervous, you're not
paying enough attention.  And there's a whole different set of issues
around how your time can get fucked up if you think the cycle-leading
sentence of your GPS is X but it's actually Y != X.

I think *our* code works reliably, because we check it on a kajillion
different NMEA variants every time I run scons testregress.  But I
don't trust anyone else's, because *nobody else tests the way we do*.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

signature.asc
Description: Digital signature