gpsd-dev
[Top][All Lists]
Advanced

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



reply via email to

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