On Mon, Nov 25, 2019 at 3:15 PM Sanjeev Gupta via devel <devel@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.
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
