Re: [gpsd-dev] GPSD and time service

[Gary E. Miller]

Yo Hal!

On Mon, 06 Jul 2015 00:03:25 -0700
Hal Murray <address@hidden> wrote:

> >>>   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.
> > Yeah, lost me too.  I'm unaware of any issues in the area of gpsd
> > and PPS. If you can flesh out a use case I'll try to explain or
> > fix. 
> 
> The context for my initial statement (way above) was cleaning up the 
> interface between ntpd and gpsd and/or other external time sources.
> 
> 
> ntpd has two ways to process PPS.

Four if you count PPS by way of SHM or GPSDJSON.

> One is buried inside the NMEA driver.  That is a pain to
> debug/monitor.  The external interface through things like ntpq shows
> either the serial data or the PPS data.  Normally, it shows the PPS.
> Then you can't tell if the serial/NMEA timing is close to broken
> because there is no way to see that data.

Ouch.  Easy to check gpsd, just start it this way:

        gpssd -nND6 /dev/ttyUSB0 | egrep 'NTP|PPS'

That will show you all the time relevant logs for both the GPS serial
(NMEA or binary) and PPS threads.

> The other is a stand alone driver.  It has to find the seconds from 
> someplace.  The way it finds that someplace is to use a server marked 
> "prefer".  It mostly works, but I sure wouldn't call it elegant.
> (I'm not even sure what happens if you have more than one server
> marked prefer.)

Double ouch.  gpsd determines the current second for the PPS for a device
from the last serial GPS time field of that same device.

So gpsd can easily report two different PPS times, at the same time,
from two GPS.

> There is another worm in this can.  The RFC describes a PLL inside
> the kernel that tracks PPS pulses.  Some kernels implement that.  I
> don't think Linux does.  (It did, many years ago.)  It seems
> reasonable to me that the interrupt handler should grab the time
> stamp, wake up a user thread, that thread could do the PLL arithmetic
> and call back in to tell the kernel what to do.  Traditionally, ntpd
> has polled the PPS data so most kernels don't implement the wakeup
> part of the PPS RFC.

gpsd handles RFC 2783 as much or as little as the host OS supports.
On Linux there is full support, so the PPS time is pretty good.

If RFC 2783 support is not available then gpsd wakes up in a select loop
and immediately grabs a system clock timestamp.  Thus a loss of a 
few microSec in latency and jitter.

> If we want to support the Kernel PLL, ntpd needs a file descriptor -
> or a back channel to gpsd (or other) to tell it when to turn the PLL
> on/off.

I am unaware of any such thing in Linux relative to the PPS.  I believe
that ntpd adjusts the kernel PLL using adjtimex() or similar.  gpsd just
needs to get the system time when the PPS is detected.  Then ntpd
and/or chronyd do the fancy math and the kernel adjustments.

> I think the current approaches (both SHM and JSON) present all the 
> information to ntpd but ntpd isn't setup to take advantge of it.

I do see that in practice chronyd does a better job than ntpd with the
data that gpsd provides.  Something internal to ntpd is losing precision.

The main problem with the current SHM implementation is security related,
the permissions are not as good as they should be.  The JSON works well,
but the ntpd defaults are sub-optimal and the configuration is less than
obvious.  There are also security issues with the JSON interface as
the client can potentially reconfigure gpsd in a bad way.

> I don't have any good suggestions.  Mostly, I was adding another
> complication to any discussion of cleaning up the gpsd-ntpd interface.

Well, if we are going to complicate things. :-)  My preferred interface
is the chronyd socket interface.  I see it as more secure than either
the SHM or JSON interfaces.

I run SHM and JSON on ntpd, and socket and SHM on chronyd, with no
problems.  Configuration details are in the gpsd time service howto.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1(541)382-8588

pgpcRLl5uI6Sd.pgp
Description: OpenPGP digital signature