[gpsd-dev] GPSD and time service

[Eric S. Raymond]

On another mailing list, Hal Murray said:

> I've never been all that happy with gpsd for use with ntpd.
>   There is a culture clash between what I want and what gpsd provides.  I 
> want the details that it is trying to hide from me.

What details do you want, exactly?  What do the ntpd GPS drivers report
that gpsd doesn't?  The JSON packet format is easy to extend; meeting a
request like this causes very little transition difficulty.

>   There is no logging from gpsd.  If something goes wrong, you have no 
> history to work with.

Eh?  There is little logging by default, but I think you'll find the
the -D option can make it as voluminous as you could possibly want.

>   It's yet another package to install and learn, and at least the setup 
> distributed by Fedora grabs all USB devices that look like TTYs so I have to 
> track that down and disable it.

Why do you have to disable it?  gpsd looks at those devices but doen't hold
on to them unless they really are GPSes.  See http://esr.ibiblio.org/?p=4319
for discussion.

   Also, people looking at this problem often jump to the conclusion that
   the failure cases are much more frequent and dangerous than they
   actually are. GPSD typically is not sending config strings to random
   devices it hasn’t identified as GPSes yet; it’s just sniffing data,
   and only immediately after a hotplug event. The worst case is that
   another class 00/FF loses a second’s worth of data, not that it gets
   accidentally told to self-destruct or something.

   UPDATE2: Another safeguard, which I had forgotten writing, is that
   under Linux GPSD uses a sadly non-portable hack which determines if
   a device has been opened by another process and if so ignores it.
   So the only way gpsd even <em>reads</em> from an unknown device is
   when no other application has claimed it.

It turns out that the only cases in which we need to send a device a
wakeup string are RS232, in which case gpsd is *not* going to
automatically open the device on a hotplug event because there aren't
any.

>   I get the feeling that time is a second class citizen for gpsd.
> For example, logging from gpsmon doesn't include the time which is
> what you need for debugging timing issues.

Gary and I recently spent considerable effort on ensuring that PPS and
TOFF are displayed in gpsmon, so we're certainly trying to move
towards better time-service diagnostics.

I question whether adding this feature in gpsmon would be putting it
in the right place, however.  If you'tr trying to collect logs for
graphing and analysis you would probably be better served by the
existing timestamping options in gpsipe.

>   The high end GPS/GPSDO units provide more info than low end GPS units.  We 
> need a way to log  that.  Examples: time/freq quality, DAC voltage to the 
> OSC, and temperature.

One difficulty here is defining a standard set of such GPSDO
statistics to be included in reporting.  Another is making a
principled decision about what times to report them.

I haven't done this because I don't yet have the right kind of domain
knowledge, but I like the idea.  If you could exhibit samples of three
or four GPSDOs outputting these I think it probably would not be
difficult to converge on a solution.

>   The prefer hack to get the second to go with a PPS should get cleaned up.

I don't know what problem you're trying to point at here, sorry. Gary
owns that part of the code, perhaps he'll have a better answer.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

Every election is a sort of advance auction sale of stolen goods. 
        -- H.L. Mencken