[ntp:hackers] GPSD client clock & latency issues

juergen perlinger juergen.perlinger at t-online.de
Thu Feb 20 19:07:19 UTC 2014


Hello Gary!

On 02/19/2014 11:20 PM, Gary E. Miller wrote:
> Yo juergen!
>
> On Tue, 18 Feb 2014 22:06:22 +0100
> juergen perlinger <juergen.perlinger at t-online.de> wrote:
>
>> Currently the client protocol does only provide usec resolution for
>> the PPS measurement. This could be changed by the GPSD team, but IMHO
>> this is not that urgent because
> nSec PPS has been in GPSD for some time with the chronyd interface.
> nSec on the ntpd SHM interface was added in the last few months.
I think using the SHM clock directly from GPSD is a hack and creates a
circular dependency. It also adds complexity to GPSD, because there are
currently at least three protocols: The JSON data stream to clients, the
SHM protocol to NPD, and the CHRONY pipe. You add protocols for specific
clients -- and that's not good.

If GPSD does the GPS evaluation (including measurement/stamping of PPS
pulses), then NTPD should be happy to use the client protocol provided
by GPSD to access the data. Keeps GPSD simple, and the server/client
roles for the GPS data are well defined and in the 'natural' direction.
>
>> The reason for requiring the PPS pulse to be present is that GPSD does
>> not measure the receive time of the GPS data records. 
> GPSD has no such requirement.  It works fine with serial only, just at
> a degraded accuracy.
Naturally. As I said before, GPSD does a wonderful job on PPS sampling
and data aggregation, but time stamping the aggregated data is neither
needed nor easy. (Too many options...) A client clock to GSPD could just
use fudge time 2 to compensate for the average delay in absence of PPS
measurements. But a lot of chipsets are not good when it comes to the
serial data timing. That's why I just stop synch'ing then. At least
right now -- this might change if requested, but I'm not fond of it.

The whole reason why I wrote up this driver was that the current ways to
connect GPSD and NTPD might be working, but a proper GPSD client driver
is much cleaner from an architectural point of view.

Cheers,
    Pearly



More information about the hackers mailing list