running without pool or other servers

Gary E. Miller gem at
Tue Sep 12 19:30:08 UTC 2017

Yo shouldbe!

On Tue, 12 Sep 2017 18:12:49 +0100
shouldbe q931 <shouldbeq931 at> wrote:

> Apologies for the delay in replying, gmail decided to file you as
> spam...

It happens.

> On Mon, Sep 11, 2017 at 9:11 PM, Gary E. Miller <gem at>
> > You are missing prefer on SHM(1).  Otherwise ntpd does not know to
> > prefer the PPS over the NMEA time.  Some would also add noselect to
> > SHM(0).  
> If I add prefer to the PPS line and noselect to the GPS line, then
> ntpq shows that the PPS line is the system peer, but from the ntp.conf
> page the GPS line is only used for display, which as I understand it
> would then mean I would need something else to set the system time,
> which would defeat the purpose of running in autonomous mode...

When you use the SHM() driver, gpsd adds the data/time from the NMEA to
the PPS.  So in that case it works.

> With only the prefer on PPS and without the noselect on GPS I did not
> see either change from x

Right, because ntpd can not decide which of the two is the correct time.

> I have also tried using the server instead of refclock lines and
> adding true to the PPS and prefer to the GPS

Gack...  Don't use the NMEA time with prefer. The point is to prefer   !
PPS time, not NMEA time                                                !

> # GPS PPS reference (NTP1)
> server minpoll 0 maxpoll 0 true

Smallest minpoll that ntpd accepts is 3.

I've never used 'true', I've never had a time source that I trusted that
much, even PPS.

> # GPS Serial data reference (NTP0)
> server minpoll 4 maxpoll 4 prefer

I'd make minpoll bigger, like 6 or 7.  You want ntpd to converge on 
SHM(1) first.

> This changes (takes several minutes) between x & o for PPS and x, +, &
> * for GPS.  I haven't seen a log message that corresponds with the
> change as seen by ntpq to be able to provide an accurate time.

As esr has pointed out, ntpd can't figure out whether to prefer PPS or NMEA.
That is the proble  you need to fix.  Simple voting is no help as there
are only 2 choices.

> To my untutored eye the server & fudge lines have been the most
> promising in that it shows the PPS as a PPS source, but then still
> rejects both as false tickers.

Two 'x' does NOT mean ntpd has not made a choice.  More than likely
ntpd has chosen the PPS.  Test with: ntptrace localhost

I just tested a RasPi with just a PPS and NMEA.  I see the two 'x',
but I also get this:

pi ntpsec # ntptrace localhost
localhost: stratum 1, offset 0.000265, synch distance 7.942550, refid 'PPS'

So all is well.

> I know I'm not looking for a left handed screwdriver, but I am
> starting to wonder if I'm looking for a wild goose (-:

Or follwoing your own tail.  I have no problem with this configuration:

pi ntpsec # cat /etc/ntp.conf

driftfile /etc/ntp.drift
statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
logfile /var/log/ntpd.log  
logconfig =syncall +clockall +peerall +sysall
restrict default nomodify notrap nopeer noquery
restrict -6 default nomodify notrap nopeer noquery
restrict mask
restrict -6 ::1
restrict mask
restrict -6 [2001:470:e815::]/64
refclock shm unit 1 maxpoll 4 refid PPS flag4 1 prefer
refclock shm unit 0 maxpoll 4 time1 0.133 refid GPS flag4 1

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the users mailing list