Dear All,
my environment:
Raspberry PI with Debian OS
gpsd: 3.26.2~dev (revision release-3.26.1-162-gfbbdab4a2)
ntpsec-1.2.4+46-g21f6610bc respectively ntp classic 4.2.8p18
I am running GPS ( or should I say GNSS ) disciplined stratum 1 NTP
servers since several years.
After of some updates I realised that a NTP server isn't running as
expected.
It used gpsd: 3.26.2~dev and ntp classic 4.2.8p18
The relevant part of ntp.conf was this:
server 127.127.22.0 minpoll 4 maxpoll 4
fudge 127.127.22.0 refid PPS time1 0.000126
fudge 127.127.22.0 flag3 1 flag4 1 # enable kernel PLL/FLL clock
discipline and clockstats
server 127.127.28.0 minpoll 4 maxpoll 4 prefer # PPS requires at least
one preferred peer
fudge 127.127.28.0 refid NMEA
fudge 127.127.28.0 time1 +0.1539 flag4 1 # coarse processing delay offset
gpsd is running as nobody in this way:
gpsd -G -n -s 9600 /dev/serial0 /dev/pps0
And the issue was, that 127.127.28.0 ( SHM(0) ) was sometimes marked as
falseticker with "x"
Or how to read in the docs "discarded by intersection algorithm"
But this was not permanent. Over a while it was OK showing a "*" with
ntpq and then later for a while it was bad "x" . And so on.
127.127.22.0 was always in state "PPS" with an "o" and never a falseticker.
The bad situation during the time of falseticker was the fact that the
system time went crazy.
I could verify this with a reference server.
As short solution I defined a second preferred server in ntp.conf
This solved the issue and the offered time from this NTP server was stable.
Whenever 127.127.28.0 failed the second preferred server
(193.171.23.162) jumped in as peer
and when 127.127.28.0 was OK ntpd decided to take 127.127.28.0 again as
peer. And so on.
Of course this was not a satisfying solution.
Happy to have another NTP stratum 1 server with a similar configuration.
And there I couldn't see this issue. The different was I am using
ntpsec-1.2.4+46-g21f6610bc
Therefore I decided to use ntpsec on this problematic server too. Wow !
Problem solved.
The graph below shows the change. Around 15 o'clock I changed from ntp
classic to ntpsec.
Explanation: Server (1) is 127.127.22.0 was always PPS as line 1.7
shows and never a falseticker.
Till 15 h server (2) 127.127.28.0 was jumping between 2.1 ( x =
falsetick ) and 2.6 ( * = peer )
During that time the second preferred server 193.171.23.162 (3) was
either peer or candidate ( line 3.4 or 3.6 )
With ntpsec after 15 h 127.127.28.0 was stable PPS ( line 2.6 ) and the
second preferred server always only candidate.
I know exactly that this mailing list has absolut nothing to do with ntp
classic.
But I also know there are several people in this list knowing the
internals from gpsd and ntpsec very well
and probably also the ntp classic details. So pardon me to post here.
As simple user it's a mystery for me that the shared memory interface
between gpsd and ntpd is sometimes working and sometimes not. Why ?
And what can cause that ntp classic has issues but ntpsec not ?
I know that ntpsec and gpsd are well adjusted to each other.
But I also know that ntp classic was also working well with gpsd in
older days. When, I can't say any more.
Any feedback is welcome with many thanks in advance.
Kind regards
Hans
--
