Re: [gpsd-dev] gpsd rolls back to 1999

[Eric S. Raymond]

Greg Troxel <address@hidden>:
> "Eric S. Raymond" <address@hidden> writes:
> 
> > Sanjeev Gupta <address@hidden>:
> >> Eric, on the gpsd TODO:
> >> 
> >> https://www.febo.com/pipermail/time-nuts/2013-August/079271.html
> >
> > Reproducing the patch here so it's part of the record of our discussion:
> >
> > --- refclock_nmea.c.orig    2010-11-10 03:38:22.000000000 +0000
> > +++ refclock_nmea.c 2013-08-13 20:05:44.000000000 +0100
> > @@ -979,6 +1076,8 @@
> >     date.yearday = 0; /* make sure it's not used */
> >     DTOLFP(pp->nsec * 1.0e-9, &reftime);
> >     reftime.l_ui += caltontp(&date);
> > +   while (reftime.l_i + 512*7*86400 < rd_timestamp.l_i)
> > +           reftime.l_i += 1024*7*86400;
> >  
> >     /* $GPZDG postprocessing first... */
> >     if (NMEA_GPZDG == sentence) {
> >
> > It does this: Look a half-era ahead.  If that's still less than a
> > reference date, shift the time stamp forward N cycles for the minimum
> > N that will take it past the reference date.
> 
> Strictly, each move forward is conditional on the time being more than
> half an era behind, rather than moving to beyond once that's satisfied
> once.  But all non-pathological situations the time will be just about
> exactly N eras behind, so that won't matter.
> 
> > I'm not certain what the reference date is, because the context doesn't
> > exactly match anything in our code.  If it were me writing the code it
> > would be the build date of the instance.
> 
> I would choose 2018-07-01, to be well before W2K, and so that it isn't
> part of some build step that 1) could go wrong and 2) leads to
> non-reproducible builds.

I could accept that as a friemdly amendment.

> > That might work, but it makes me nervous. Perly is not a dimwit; if 
> > compensating for wraparound is that easy, why the magic calendar hack?
> 
> I think it really is that easy.  The issue is that the higher-order bits
> were truncated in the on-air message (per spec, not a bug) and the
> receiver assumed zero instead of keeping track.  There is the issue that
> receivers are running their own code like this with pivot dates and
> keeping track, but if the time reported is well before now, it seems
> safe to move forward one epoch.

Plausible.  

> Can someone explain "magic calendar hack"?  Maybe that is addressing a
> different receiver bug.

Have a good hard look at ntpd/ntp_wrapdate.c. The functions unfold_century()
and eval_gp_time() are clrarly doing morte elaborate versions of this sort
of periodic extension.

> > This whole area is full of traps.  We need to proceed very carefully.
> 
> Agreed we should be careful.   To me, that means sticking to first
> principles and specs and choosing the minimal or near-minimal correct
> fix.

Agreed.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>