Re: [gpsd-dev] Draft Time Service HOWTO is beginning to approach final form

[Eric S. Raymond]

Andy Walls <address@hidden>:
> WARNING: In the case of a GPS unit that inserts an unannounced second
> due to downloading an updated GPS-UTC leap-seconds correction from the
> GPS almanac after start-up, the falseticker declaration for the GPS unit
> will happen some time less than 12.5 minutes (IIRC) after startup.  I
> have had two ntpd configs trying to deal with this sort of thing and
> both failed to work properly.  One config caused ntpd to declare the GPS
> unit a flaseticker forever,  The other ntpd config accepted the step
> from the GPS unit, but ntpd took an ?hour? (my memory is fuzzy here) to
> slew the clock to the GPS time.

Well, shit.

This puts some more oomph behind my uneasiness about ntpd having direct 
NMEA support.  The failure scenario that worries me most is one in which
the driver makes a wrong assumption about what sentence the GPS emits
first in the reporting cycle and as a result aggregates a timestamp 
with an off-by-one seconds value.

You're telling me that ntpd will not do a good job of recovering from this.

This can't happen in gpsd because I built a start-of-cycle detector 
into the NMEA-parsing code to deal with this exact case.  Its cost is
that it may discard data from the first two cycles, but after that
you know for sure what the start of cycle is and will never accidentally
aggregate data from two different fix-reporting cycles.

Since the PPS code waits for 4 good fixes before shipping to ntpd

> Sorry for the novel.

Yeah, that recipe is too complex for us to use.  Maybe Beat will pull
another rabbit out of his hat :-)
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>