Re: [gpsd-dev] GPS week wraparound

[Eric S. Raymond]

Andy Walls <address@hidden>:
> It is obvious the GPS unit has an initial, hard-coded leap second count
> that is out of date. 

Good point.  I've inserted a sentence about this.  Since I had added a 
'graph about PPS that will be of interest to NTP people shortly after that,
here's how the whole last section now reads:

  5) Another source *may* be available - the GPS leap second count, if we can
  get the device to report it. The latter is not a given; SiRFs before
  firmware rev 2.3.2 don't report it unless special subframe data reporting
  is enabled, which requires 38400bps. Evermore GPSes can't be made to
  report it at all. Furthermore, before the almanac load the GPS may report
  a fixed (and possibly out of date) offset.

  Conclusion: if the system clock isn't accurate enough that we can deduce
  what rollover period we're in, we're utterly hosed. Furthermore, if it's
  not accurate to within a second and only NMEA devices are reporting,
  we don't know what century it is!

  Therefore, we must assume the system clock is reliable to within a second.

  However, none of these caveats affect the usefulness of PPS, which 
  tells us top of second to 50ns accuracy and can be made to condition a
  local NTP instance that does *not* rely on the system clock. The 
  combination of PPS with NTP time should be reliable regardless of
  what the local system clock gets up to.

I left out my worries about bufferbloat-induced NTP clock skew...
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>