Re: [gpsd-dev] Time autonomy

[Eric S. Raymond]

Hal Murray <address@hidden>:
> Looks good to me.
> 
> Note that we have already had 1 week rollover so you can test most of the 
> code by building with constants set to long ago.

Agreed.  One of my to-dos is to write synthetic test loads to check the 
behavior of the implementation at critical points, like within a second
either way of a rollover date.
 
> I think the NMEA vs binary devices area needs clarification.
> 
> At least one NMEA sentence gives a 4 digit year.

That'd be GPZDA.

>              With a 4 digit year you can 
> compute the epoch directly, at least until 3000.  With a 2 digit year, it 
> only works until 2100.  I'm assuming they will use the build-date trick so 
> the year will be correct for 20 years after the device (or its firmware) is 
> built, or much longer when the 13 bit week gets implemented.
> 
> Assuming you compute an epoch from the NMEA date, I think there are several 
> cases:
>   If gpsd build epoch == NMEA epoch:  simple case, use it
>   if gpsd epoch < NMEA epoch:
>     new NMEA, use future epoch from NMEA
>   if gpsd epoch > NMEA epoch:
>      old NMEA lies, bump epoch from NMEA (maybe multiple times)

This smells too complicated to me, like you're trying to squeeze more
information out of the date than is actually there.  It's really just
(week, tow, leap_offset) underneath.
 
> Do binary devices provide any info that can be used to derive the epoch?  
> Perhaps a firmware date or hardware manufacturing date?

Some appear to, but I'd hate to rely on the format of that data being
stable in future versions.  I've seen it change too often in SiRFs.

> > This will yield nearly correct time provided the device is on continuously
> > on from a date during its build era (e.g. before the first rollover after
> > BUILD_EPOCH), and gets at least one valid fix per week. 
> 
> I think it's better than that, or at least more complicated.

It is a little better.  But *because* it's more complicated, as the
latency period gets longer I become less sure there aren't troublesome
edge cases. One sample a week guarantees two samples bracketing every
rollover and every leap-second insertion.

> Some devices have a way to tell them the date/time.  Perhaps we should 
> document the gpsctl incantations someplace.

I'll probavbly write a JSON request that can be used to set the epoch.

> > To upgrade so the algorithm can handle shutdown periods, add two steps: 
> [/var/run/gps-epoch...]
> 
> Without that, it works for 20 years past the build date, including shutdown 
> periods.
> 
> Is that good enough?  Is working for more than 20 years worth the complexity 
> of what happens when a file gets mangled and documenting things so admins can 
> debug it and ...?

It's worth it so people won't say "What about this big freaking obvious
falure case?" :-)

> An alternative source of the epoch is the file system.  I think some OSes 
> running on systems that don't have have a battery-backed RTC/TOY use that to 
> set the initial time.  I think there is something like a last-update-date on 
> the mount point for the root file system that gets updated frequently.  I 
> don't know how well that works in practice.

Yeah.  I specifically don't want to go there - because in the SBC-at-sea
case, the file mod time itself might derive from th GPS.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>