[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>
- Re: [gpsd-dev] Planning a 3.11 snap release, (continued)
- Re: [gpsd-dev] Planning a 3.11 snap release, Greg Troxel, 2013/11/26
- Re: [gpsd-dev] Planning a 3.11 snap release, Eric S. Raymond, 2013/11/26
- Re: [gpsd-dev] Planning a 3.11 snap release, Greg Troxel, 2013/11/26
- Re: [gpsd-dev] Planning a 3.11 snap release, Eric S. Raymond, 2013/11/26
- Re: [gpsd-dev] Planning a 3.11 snap release, Greg Troxel, 2013/11/26
- Re: [gpsd-dev] Planning a 3.11 snap release, Eric S. Raymond, 2013/11/26
- Re: [gpsd-dev] Planning a 3.11 snap release, Gerry Creager - NOAA Affiliate, 2013/11/26
- Re: [gpsd-dev] Planning a 3.11 snap release, Hal Murray, 2013/11/26
- Re: [gpsd-dev] Planning a 3.11 snap release,
Eric S. Raymond <=
- Re: [gpsd-dev] Planning a 3.11 snap release, Hal Murray, 2013/11/26
Re: [gpsd-dev] Planning a 3.11 snap release, Greg Troxel, 2013/11/24
Re: [gpsd-dev] Planning a 3.11 snap release, Gary E. Miller, 2013/11/25