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

[Andy Walls]

On Thu, 2013-10-24 at 16:21 -0400, Eric S. Raymond wrote:
> 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.

For a definition of "good job".

Please keep in mind, the system on which this behavior was observed is
unusual in a few ways: no batteries/hold-up, no internet connectivity,
and ntpd.conf tweaked in bizarre ways to allow time jumps.

That said, NTPD does not like random, unannounced jumps in time.  NTPD's
way of dealing with this is to be paranoid and untrusting of the clock
that jumped.  That is probably the right response (i.e. "good job") for
99% of NTPD's use cases.

I do not know if NTPD will gracefully handle an unannounced leap-second
that happens just before midnight June 30 or December 31.


I believe, if a refclock that jumped comes back into line, then NTPD
eventually trusts it again.  I do not know the exact criteria and
process by which NTPD decides a refclock is no longer a falseticker.



> 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


For my case, I need to have wait for 4 good fixes + indication that the
almanac has been downloaded and the current GPS-UTC correction has been
applied.  Having a fix and having good time can happen at two distinct
points in time for my setup.

I was going to hack up my GPSD to indicate a clock alarm to NTPD until I
know my device is providing good time.
  
A Trimble distributor tech support person told me that, for my Trimble
Condor chip, "[in] the [$GP]GLL output, UTC is not included until the
offset has been decoded".  I need to experimentally verify that; but
that could be an easy way for me to know when time from my device is
actually good.

Regards,
Andy