Re: [gpsd-dev] SHM refclock improvements

[Miroslav Lichvar]

On Tue, Aug 28, 2012 at 03:07:51AM -0700, Harlan Stenn wrote:
> We're looking to improve NTP's SHM refclock interface.
> 
> I expect we will keep modes 0 and 1 the same (bit 0), and use bit 1 to
> indicate that the base units will be nanoseconds instead of
> microseconds.
> 
> Similarly, I expect we'll use a union of two structures, the original
> struct shmTime (or make a subset of that structure the union) and the
> new layout; the 'mode' value will be in the same place in the structure.
> 
> http://support.ntp.org/bin/view/Support/ImprovingTheSHMRefclock is where
> we're tracking this work.  If you have any ideas or comments, please
> submit them there.

I know most of us seek for perfection, but is it really necessary
here? Why not go with the approach proposed in the original bug #1232? 

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.

It will be just couple lines of code on both sides and it will be
backward compatible in both directions. Is it a hack? Yes. But it will
work. Let's not waste time on implementing some complicated protocol
version negotiation.

For the other issues with SHM, if they really cause some problems,
it's probably better to make a new protocol from scratch instead of
trying to extend SHM.

-- 
Miroslav Lichvar