running without pool or other servers
Gary E. Miller
gem at rellim.com
Tue Sep 12 19:30:08 UTC 2017
On Tue, 12 Sep 2017 18:12:49 +0100
shouldbe q931 <shouldbeq931 at gmail.com> wrote:
> Apologies for the delay in replying, gmail decided to file you as
> On Mon, Sep 11, 2017 at 9:11 PM, Gary E. Miller <gem at rellim.com>
> > 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 127.127.22.0 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 127.127.28.0 minpoll 4 maxpoll 4 prefer
I'd make minpoll bigger, like 6 or 7. You want ntpd to converge on
> 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
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
logconfig =syncall +clockall +peerall +sysall
restrict default nomodify notrap nopeer noquery
restrict -6 default nomodify notrap nopeer noquery
restrict 127.0.0.1 mask 255.255.255.0
restrict -6 ::1
restrict 184.108.40.206 mask 255.255.255.0
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 rellim.com 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
Size: 488 bytes
Desc: OpenPGP digital signature
More information about the users