Re: [gpsd-dev] RC for DRIFT message

[Eric S. Raymond]

Hal Murray <address@hidden>: 
> You didn't mention "JSON", but I think the context of your message assumed 
> that.

Yes.

> I'd like to review the whole tangle of how to pass info from gpsd (or 
> similar) to ntpd.  Currently, we have implementations for one version of 
> shared memory and JSON over TCP.  Getting a good/clean shared memory 
> implementation is high on my list.  Message Queues have been suggested.  How 
> about pipes?

This is possible.

> I think you said you were going to think about this area.  I hope that grows 
> into a good web page explaining all the tradeoffs and problems.  I'm still 
> slightly surprised that there isn't a good web page describing how to use 
> shared memory for the environment we have: either side can start first and 
> either side can crash or restart at any time.

The idea of writing a HOWTO is an excellent one, thank you.  I believe I am
well equipped to do it, and it would be good battlespace preparation for 
redesigning the reporting mechanism to NTP.

> We should consider writing simple debugging/testing tools too.

One of the possibilities I'm contemplating for the next cycle is a
real-time strip-chart visualizer that reads from the NTP shared-memory
segment and plots the PPS offset over time.  There's a Python library
called stripchart.py that works with my favorit graphics toolkit,
pygtk; the only mildly grotty part will be writing the C Python extension
to read from the segment.

> > Almost everything about this feature is easy to specify.  We can call it
> > DRIFT or CLOCKDRIFT and it can have the same members PPS does - second and
> > nanosecond parts for real (GPS) and CPU clock time. 
> 
> Drift is a poor choice of words.  It's already well known in the ntp context 
> as the frequency offset rather than a time offset.  If the frequency is off, 
> your clock will drift.

You're right.  I think it's going to be TOS (top of second).
 
> I'd also like to see some indication of quality.  I don't have any good 
> ideas.  A real simple one is the number of satellites.  Another is offset 
> from a known location (which doesn't work if the receiver is in time mode).  

This will require thought.

> Is there a DOP for time?  What fraction of devices provide it?

There is.  It is almost never reported, but we compute it from the
skyview as part of our error modeling.  The only issue is that I'm not
sure what the dimension of TDOP * UERE (the base user error in meters)
is.

> It's common (or at least not uncommon) for a default NMEA setup to send the 
> satellite info every 5 seconds.  If that stuff comes before the first message 
> with time in it, there might be a lot of jitter.

In NMEA devices it is usually the case that GPMRC and GPGGA are emitted early
and GPGSV/GPGSA late.

>                                           It might be appropriate to 
> use the start time of the first message in the clump but delay sending 
> anything until you actually receive a message with time and a valid flag.

I think that last thing is what's going to happen.  By useful coincidence this 
will be the same time that the unit 0 report is shipped to NTP.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>