Please review this document fragment

[James Browning]

On Mon, Nov 25, 2019 at 3:15 PM Sanjeev Gupta via devel <devel at ntpsec.org>
wrote:

> From: docs/driver_shm.adoc
>
> Is the first paragraph still required, if it doesn't apply to current
> nrpsec?
>
> And I cant parse the second paragraph, especially the first line.  What
> should I use?  Not the ancient method, surely?
>
>
> The _GPSD_ man page suggests setting minpoll and maxpoll to 4. That was
> an attempt to reduce jitter. The SHM driver was fixed (ntp-4.2.5p138) to
> collect data each second rather than once per polling interval so that
> suggestion is no longer reasonable.
>
> *Note:* The _GPSD_ client driver uses the _GPSD_ client
> protocol to connect and talk to _GPSD_, but using the SHM driver is the
> ancient way to have _GPSD_ talk to _ntpd_. There are some tricky points
> when using the SHM interface to interface with _GPSD_, because _GPSD_
> will use two SHM clocks, one for the serial data stream and one for the
> PPS information when available. Receivers with a loose/sloppy timing
> between PPS and serial data can easily cause trouble here because _ntpd_
> has no way to join the two data streams and correlate the serial data
> with the PPS events.
>

It still does a little. You could but probably shouldn't use text like
the following paragraph instead.

The _GPSD_ man page suggests setting minpoll and maxpoll to 4. This only
applies to old (pre 4.2.5p138) versions of classic ntpd. The suggested
means of connecting to a local GPSD instance is to use the gpsd refclock.
the SHM refclock driver lacks a mechanism to correlate PPS information
with the data stream. Receivers without tight/strict timing may cause
trouble here.

Additional verbiage complimenting this might be added to the gpsd
refclock files.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20191125/b1c56476/attachment-0001.htm>