gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Greg Troxel
Subject: Re: [gpsd-dev] gpsd rolls back to 1999
Date: Fri, 28 Jun 2019 10:42:41 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (berkeley-unix)

"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.

> 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.

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

> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]