[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-dev] SHM refclock improvements
From: |
Terje Mathisen |
Subject: |
Re: [gpsd-dev] SHM refclock improvements |
Date: |
Thu, 30 Aug 2012 07:43:14 +0200 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120715 Firefox/14.0.1 SeaMonkey/2.11 |
Gary E. Miller wrote:
Yo Miroslav!
On Wed, 29 Aug 2012 11:03:22 +0200
Miroslav Lichvar <address@hidden> wrote:
Allocate two ints from the dummy array for clockTimeStampNSec and
receiveTimeStampNSec, the client fills all usecs and nsecs fields, and
the server uses the nsec fields only if nsec / 1000 == usec. That's
it. If they match by accident, it's noise below microsecond.
Good idea!
You really don't want a real division in order to do that comparison,
but all modern compilers will optimize a constant division with a
reciprocal multiplication instead, so that the real cost will be less
than 10 clock cycles for optimized code.
Alternatively, code it like this:
ns = shm->us_field*1000;
ns_exact = shm->ns_field;
if ((ns_exact - ns) < 1000)
ns = ns_exact;
and use the (ns) variable further on
I checked gpsd and the entire shmTime structure is first zeroed before
use. So that should work and be forward/back compatible. I could add
that to gpsd git in a few minutes.
As long as we know an 'int' will be at least 4 bytes. Do we know that?
We know that the us field is large enough to store 20-bit quantities, so
as long as it is a power of two it has to be at least 32 bits.
Making the ns field the same size should therefore be sufficient.
With a reasonably new compiler you should have int32_t, uint32_t,
int64_t etc available, those would of course be better than an array of
ints.
Terje
--
- <address@hidden>
"almost all programming can be viewed as an exercise in caching"
- Re: [gpsd-dev] SHM refclock improvements, (continued)
- Re: [gpsd-dev] SHM refclock improvements, Gary E. Miller, 2012/08/28
- Re: [gpsd-dev] SHM refclock improvements, Harlan Stenn, 2012/08/28
- Re: [gpsd-dev] SHM refclock improvements, Gary E. Miller, 2012/08/28
- Re: [gpsd-dev] SHM refclock improvements, Dave Platt, 2012/08/28
- Re: [gpsd-dev] SHM refclock improvements, Harlan Stenn, 2012/08/28
- Re: [gpsd-dev] SHM refclock improvements, Eric S. Raymond, 2012/08/28
- Re: [gpsd-dev] SHM refclock improvements, Hal Murray, 2012/08/28
- Re: [gpsd-dev] SHM refclock improvements, Eric S. Raymond, 2012/08/28
Re: [gpsd-dev] SHM refclock improvements, Miroslav Lichvar, 2012/08/29