running without pool or other servers

[Eric S. Raymond]

shouldbe q931 <shouldbeq931 at gmail.com>:
> I am attempting to run ntpsec in a "standalone" instance where it is
> only provided time and PPS from a GPS receiver (via gpsd).
> 
> The relevant lines in ntp.conf I have arrived at are
> 
> # GPS PPS reference (NTP1)
> refclock shm unit 1 refid PPS minpoll 0 maxpoll 0
> 
> # GPS Serial data reference (NTP0)
> refclock shm unit 0 prefer minpoll 4 maxpoll 4 time1 +0.118 stratum 1
> refid GPS flag1 1
> 
> The time1 time has been calculated for the instance.
> 
> ntpsec was configured with "./waf configure --refclock=all"

That looks correct.

> While running "watch -n1 ntpq -p" I see the PPS line alternate between
> x and o and sometimes +, and the GPS line alternate between x and *
> 
> The reach remains at 377 for both the PPS and GPS lines when the line
> prefix changes between x and * or o or +
> 
> While running cgps -s at the same time I do not see any drops in the GPS signal.
> 
> I presume I have missed something basic, but have reached a "can't see
> the wood for the trees" point and would appreciate any guidance as to
> what I have missed.

The status codes are documented as follows:

|============================================================================
| Code| Message         | T   | Description
|  0  |  sel_reject     |     | discarded as not valid (TEST10-TEST13)
|  1  |  sel_falsetick  |  x  | discarded by intersection algorithm
|  2  |  sel_excess     |  .  | discarded by table overflow (not used)
|  3  |  sel_outlier    |  -  | discarded by the cluster algorithm
|  4  |  sel_candidate  |  +  | included by the combine algorithm
|  5  |  sel_backup     |  #  | backup (more than tos maxclock sources)
|  6  |  sel_sys.peer   |  *  | system peer
|  7  |  sel_pps.peer   |  o  | PPS peer (when the prefer peer is valid)
|=============================================================================

On your PPS line, o and + are good statuses.  The 'x' status means that the
PPS signal is being discarded.  On your GPS in-band data, '*' is a good status.

The reach value just tells you that it's consistently getting reports from both
sources, which is not surprising as you report continuous GPS fix.

I don't think you're missing anything.  My best guess is that the
internal algorithm for casting out falsetickers is thrashing because
it's seeing only one clock source.

Before I did the autonomous-mode capability on Aug 30 it could
generally expect a minimum of 4 sources, because local refclocks
literally did not work without prior synchronization to network peers.
You are the first person to report trying to use autonomous mode in
practice.

One way to test this would be to add more GPSes and then see if
the incidence of 'x' status on all devices falls.

Gary, Hal: I think you guys understand the source-selection algorithm
better than I do. Do you have any insight into this?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.