RE: Using non-PPS receiver for ntpd?

[Stein, Josh]

Hi Greg,

  I think you may have hit the nail on the head - my issue may be in ntpd 
configuration and not really with gpsd. AFAIK, gpsd is running fine, has a 3D 
fix and is writing to shared memory:

ipcs -m

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x4e545030 0          root       600        80         2
0x4e545031 1          root       600        80         1
0x4e545032 2          root       666        80         1
0x4e545033 3          root       666        80         1
0x4e545034 4          root       666        80         1
0x4e545035 5          root       666        80         1
0x4e545036 6          root       666        80         1
0x4e545037 7          root       666        80         1
0x47505344 8          root       666        24232      1

But the output from ntpq doesn't look good to (my untrained) eye:

ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 us.pool.ntp.org .POOL.          16 p    -   64    0    0.000    0.000   0.001
 SHM(0)          .GPS.            0 l    -   64    0    0.000    0.000   0.000

I'm currently focusing on the "pool" entry of the ntp.conf as a possible 
culprit for my (apparent) problem. As you stated, this is not a gpsd specific 
issue so that debugging path likely does not belong here on this mailing list. 

As an aside, your use-case described at the end of your last message is exactly 
what I am trying to do.

--Josh



-----Original Message-----
From: Greg Troxel <gdt@lexort.com> 
Sent: Wednesday, June 9, 2021 10:30 AM
To: Stein, Josh <josh@anl.gov>
Cc: gpsd users <gpsd-users@nongnu.org>
Subject: Re: Using non-PPS receiver for ntpd?


"Stein, Josh" <josh@anl.gov> writes:

>   So in this instance (not using PPS), do I just ignore any mention of
>   configuration when moving forward with the guide? Also just leaving
>   out the PPS section of the ntp.conf?

probably.  Most of my experience either predates the HOWTO or I wasn't looking 
at it.

> e.g. do not enter the lines :
>
>    # GPS PPS reference (NTP1)
>    server 127.127.28.1 prefer
>    fudge 127.127.28.1 refid PPS

You can enter them or not.  That just tells ntpd to expect a PPS source in gpsd 
shm location 1, and gpsd won't be writing it.

So really it's just

  running gpsd

  putting the 127.127.28.0 line in ntp.conf, and I'd use 100 ms
  as the fudge until you have a better estimate.

Looking at the HOWTO briefly, it is highly focused on PPS and high accuracy.  I 
don't know of any documents that try to explain the path to sub-100ms accuracy 
with serial only.  That's partly because it's just not that hard, and partly 
because some here don't want to do that.

Note that there are lots of issues with configuring ntpd, such as using network 
servers and whether ntpd should be able to follow just the local
reference with no others (tos minsane, etc.).   These really aren't
about gpsd.

Long ago, I set up a system running gpsd with a u-blox 4 and ntp, and had about 
100 computers synced to it.  We had no even semi-reliable internet, and all the 
computers being within 10s of ms of each other and
50 ms of real time was considered a great outcome, suitable for data collection 
for what we were really trying to do.