gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] Planning a 3.11 snap release


From: Eric S. Raymond
Subject: Re: [gpsd-dev] Planning a 3.11 snap release
Date: Tue, 26 Nov 2013 14:59:51 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

Hal Murray <address@hidden>:
> 
> address@hidden said:
> > GPSD is, in cold fact, that special.  It's used in life-critical navigation
> > and IFF systems.  This justifies extraordinary measures to get something as
> > basic as the time right. 
> 
> Then it's important to not set expectations that you can't fulfill.  I think 
> that means documenting the limitations rather than pretending that you have 
> covered all the weird cases.

Agreed. This is one reason I'm now thinking about computing a time confidence
level internally and using it to condition the time error estimate report.
 
> In the past few weeks, we've been discussing two areas:  leap seconds and the 
> epoch.
> 
> The GPS epoch is 1024 weeks which is about 20 years.
> 
> The trick of using the build time (or install time) of the code is a good 
> one, but it only works for 20 years.  I'll bet some old reliable legacy gear 
> will still be running 20 years after it gets built.

The next block of sats pushes the counter to 13 bits.  This will push the
problem off 150 years.
 
> I'm not worried about getting the right century from NMEA devices.  Plugging 
> in 2000 will work for another 86 years.  Somewhere in there we can use the 
> build-date trick.

Yes.

> The similar trick of compiling in the current leap-second offset doesn't work 
> as well.  They happen too often and using a default masks the problem.

However, in some cases (u-blox 5 and 6 is one) you know what the default is. 

> As a developer, I find it slightly annoying that every time I build gpsd, it 
> wastes time fetching data that hasn't changed.  I'd be happy with a local 
> copy that was assumed valid for a day or week.  Ideally, it would be stored 
> in git so one fetch would apply to all the developers and git-pull or scons 
> -c didn't blow it away.

I have a trick up my sleeve.

Because we know when the schedule slots for changing leap-seconds are, we
can in principle only do the fetch once per three-month period. I will
implement this optimization at some point.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>



reply via email to

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