gpsd or native

[John Thurston]

On 9/22/2022 10:43 AM, James Browning wrote:
> > John Thurston <john.thurston at alaska.gov> wrote:
> > 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.


That sentence confuses me, James. Was it written as a question? (i.e. 
"gpsd supports these other things. Isn't that enough reason to use it?")

In my case, the built in reference drivers are handling my desired GPS 
sentences correctly, and my PPS is working just fine. They've been 
running for a few weeks without incident, and delivering a less jittery 
time than my previous installation (using the same GSP module and 
refclocks with ntpd). I'm looking for a compelling reason to change to 
"refclock shm" and gpsd on this new ntpsecd installation.

But since it has obviously been running for several weeks now, the 
urgency of my question is low. If this remains stable for a few more 
weeks, I'll probably bolt it into my production system as one of the 
time sources.


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


Me thinks an email list server which sits on messages for months and 
months is more of a hindrance than a help. What are my other choices to 
talk to people who care about ntpsecd? I haven't looked, is 
comp.protocols.time.ntp still active?


--
Do things because you should, not just because you can.

John Thurston    907-465-8591
John.Thurston at alaska.gov
Department of Administration
State of Alaska
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/users/attachments/20220922/369ab474/attachment.htm>