Re: [gpsd-dev] GPSD and time service

[Hal Murray]

>>>   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.

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.

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.)



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.

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


-- 
These are my opinions.  I hate spam.