<!doctype html>

<html>

 <head> 

  <meta charset="UTF-8"> 

 </head>

 <body>

  <div class="default-style"> 

   <div class="default-style">

    On 2022/09/22 at 1:41:21 PM PDT, John Thurston wrote:

    <br>> On 9/22/2022 at 10:43 AM, James Browning wrote:

    <br>> > > John Thurston <john.thurston at alaska.gov> wrote:

    <br>> > > My question is this: Four years on, is this still a valid reason to

    <br>> > > prefer /gpsd/ to using the 127.127.20.0 and 127.127.22.0 reference 

    <br>> > clock

    <br>> > > drivers for GPS and PPS?

   </div> 

   <div class="default-style">

   </div> 

   <div class="default-style">

    > > Support for devices that talk things other than NMEA 0183 and

> > slightly atypical PPS wiring isn't enough.

   </div> 

   <div>

   </div> 

   <div class="default-style">

    > That sentence confuses me, James. Was it written as a question? (i.e. 

    <br>> "gpsd supports these other things. Isn't that enough reason to use it?")

   </div> 

   <div class="default-style">

   </div> 

   <div class="default-style">

    Yes, that was pretty much it. gpsd exists to protect clients

    <br>needing info from things like navigation receivers from

    <br>the misbehavior of the hardware. To a degree, it can do automatic

configuration of baud rate and parity.

   </div> 

   <div class="default-style">

   </div> 

   <div class="default-style">

    > In my case, the built in reference drivers are handling my desired GPS 

    <br>> sentences correctly, and my PPS is working just fine. They've been 

    <br>> running for a few weeks without incident, and delivering a less jittery 

    <br>> time than my previous installation (using the same GSP module and 

    <br>> refclocks with ntpd). I'm looking for a compelling reason to change to 

> "refclock shm" and gpsd on this new ntpsecd installation.

   </div> 

   <div class="default-style">

   </div> 

   <div class="default-style">

    > But since it has obviously been running for several weeks now, the 

    <br>> urgency of my question is low. If this remains stable for a few more 

    <br>> weeks, I'll probably bolt it into my production system as one of the 

    <br>> time sources.

   </div> 

   <div class="default-style">

    <br>> > Messages on the mailing list tend to take too long to arrive. I

    <br>> > think the delay is up to two months at this point (post through

> > California is faster). We should keep the posts list mirrored.

   </div> 

   <div class="default-style">

    <br>> Me thinks an email list server which sits on messages for months and 

    <br>> months is more of a hindrance than a help. What are my other choices to 

    <br>> talk to people who care about ntpsecd? I haven't looked, is 

> comp.protocols.time.ntp still active?

   </div> 

   <div class="default-style">

   </div> 

   <div class="default-style">

    The google group is more active than most of Usenet at this point.

    <br>There are also Internet Relay Chat channels at libera.chat #ntp,

    <br>#gpsd, and #ntpsec for specific software packages. #ntpsec is

pretty dead at this point, as is freenode.net.

   </div> 

  </div>

 </body>

</html>