[Top][All Lists]

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

Re: [gpsd-dev] Parallel build broken?

From: Eric S. Raymond
Subject: Re: [gpsd-dev] Parallel build broken?
Date: Sun, 24 Nov 2013 18:56:18 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

Paul Fertser <address@hidden>:
> On Sat, Nov 23, 2013 at 06:45:38AM -0500, Eric S. Raymond wrote:
> > > Or you can mark the time as inaccurate indefinitely until an external
> > > confirmation is received via gpsdctl (I can imagine a system of
> > > scripts that would start an NTP daemon and gpsd and would monitor the
> > > time discrepancy between the GPS receiver source and the other sources
> > > and once it's comfortably less than a second, tell gpsd that it's
> > > getting a fully valid signal).
> > 
> > Bletch.  Complicated...
> It seems to be the only way that's guaranteed to work
> reliably. Everything else is more or less guesswork, I'm afraid. Do I
> miss anything?

That adds a very large amount of fragile complexity to solve a
transient problem.  Scripts to start an NTP daemon? Wait for positive
ACK before clearing the inaccuracy bit?  Really?  That's awful; I
could write a *book* on the implied failure modes.

A more conservative but much simpler strategy would be simply to bump
up ept in the JSON reports by N seconds for 12.5 minutes (one almanac
transmission period) after device powerup, where N is the maximum
number of possible leap-seconds issued between the build date of the
GPSD instance and now.

These can occur at minimum intervals of three months, so if BTIME is the
build time in Unix time the formula could be 

N = ceil((time(now) - BTIME) / (90 * 24 * 60 * 60))

Yes, I know, compiling the build timestamp into the build destroys
build reproducibility.  Engineering is tradeoffs.
                <a href="";>Eric S. Raymond</a>

reply via email to

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