gpsd or native

James Browning jamesb192 at jamesb192.com
Thu Sep 22 18:43:22 UTC 2022


John Thurston <john.thurston at alaska.gov> wrote:
> Eric Raymond's HOWTO for a stratum 1 server
> <https://www.ntpsec.org/white-papers/stratum-1-microserver-howto/> uses
> /gpsd/ to provide the GPS data to ntpsec.

> It explains the decision with this:

> /If you are already familiar with ntpd and wonder why this recipe uses
> gpsd through SHM rather than ntpd’s native refclock 20 GPS driver, the
> answer is this: when refclock 20 is configured to use 1PPS, it mixes
> in-band time data with 1PPS in a way that causes it to behave badly, and
> possibly get rejected as a falseticker, when 1PPS is only occasionally
> available./

I don't see any significant-looking changes in the commits
messages except cleanups and refactors until earlier this year.
(which would not be in 1.2.1)

> The history notes on the page indicate it was first published late in
> 2016, and last updated in the middle of 2018. There has been a lot of
> water under the bridge, and many changes to ntpsec since then.

> My question is this: Four years on, is this still a valid reason to
> prefer /gpsd/ to using the 127.127.20.0 and 127.127.22.0 reference clock
> drivers for GPS and PPS?

Support for devices that talk things other than NMEA 0183 and
slightly atypical PPS wiring isn't enough.

John Thurston <john.thurston at alaska.gov> later revised:
> My question is this: Four years on, is this still a valid reason to
> prefer /gpsd/ and /refclock shm/ over /refclock nmea/ and /refclock pps/ ?

> In my mind, using the /refclock shm/ and also running /gpsd/ is more
> complication than relying on the two /refclock/ already available. But
> if the latter is prone to unexpected failures, then there are good
> reasons to accept the complication of the former.
 
> (Apologies if this is a duplicate message. I have not received my copy
> of the message I sent earlier this month, nor has it appeared in the
> web-archives, nor have I received any reply to my query to the
> users-owner email address.)

Messages on the mailing list tend to take too long to arrive. I
think the delay is up to two months at this point (post through
California is faster). We should keep the posts list mirrored.
 
JamesB192 -- Not on the team anymore
Last person hanging around.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/users/attachments/20220922/da8ed95b/attachment.htm>


More information about the users mailing list