On 08/02/19 12:49, Andrew Harrison wrote:
On Wednesday, July 31, 2019 at 7:23:52 PM UTC-4, Chris wrote:
If you have 2 servers, both gps, then the polling host needs to
have config to allow fallback to the second unit when it fails.
Yes, definitely. The problem is that it doesn't "fail" per se. When the
Symmetricom stops indicating that it's stratum 1, ntpd does not react to this. It will
keep right on using the Symmetricom as its preferred time source.
Not a time server issue afaics, unless each has fallback ability in
itself.
What you could do is run ntpd on a third host, polling both time
servers along with a host or two from an ntp pool, which should have
the ability to spot the outlier and continue providing accurate time.
Not sure about the overall behavior, but wouldn't take long to set
it up and check results...
Chris
I have ntpd set up on my workstation configured to poll all of my time servers
(2 Symmetricom, 2 Meinberg). The primary Symmetricom is set to 'prefer' in my
ntp.conf. When I yank the GPS antenna off of the primary Symmetricom, it stops
reporting itself as stratum 1 (and LI goes to 3), but ntpd does _not_ respond
to this and will keep using it as preferred. I've had the GPS antenna
unplugged for 3 days now and ntpd is still using it as its primary source.
Another interesting symptom... If I have ntpd stopped, then unplug the GPS
antenna from the Symmetricom, then start up ntpd, then ntpd knows that the
Symmetricom is not stratum 1, it automatically sets it to stratum 16 presumably
because the Symmetricom is not reporting any stratum level at this point, and
then ntpd will lock on to one of the other sources. Next, I plug the GPS
antenna back in, ntpd sees this, notices that it's stratum 1, and after a while
it will start using this as its primary time source. Then I unplug GPS again
and ntpd will keep right on assuming that the Symmetricom is stratum 1.
It's almost like there's a bug in ntpd. (Granted, you'd think that the
Symmetricom should start indicating a higher stratum level and starting
advertising a perhaps-configurable stratum level.)
A couple of points. Depending on the time server, even with a
disconnected or unlocked gps, one would expect it to hold the
last good value until the gps again locks. Also, some systems
have a "smart clock" mode, which first calculates the
ageing rate of the oscillator, then applies corrections, with a
guaranteed maxiimum offset, say over a 24 hour period. Telco
uses gps based systems for timing. Holdover and max offset
values are a typical requirement. The overall effect of that
means that an external poll may not see much change for some
time.
The other point is that even if a server loses lock, seems
that ntp would still use it, until it goes out of tolerance.
With a typical polling interval of 64 seconds, it may take many
samples until it is deemed out of tolerance. Seems that ntp
doesn't care about stratum reported from a remote server
primarily, but makes it's decisions based on calculated offset
and jitter etc, when compared to it's peers.
Disconnected the antenna from one server in the experimental
rig earlier today. 3 local servers and one external, with 1pps
feed from the .168 server. Normally, ntpq -p reports something
like:
root@ntp-host:/etc # ntpq -p
remote refid st t when poll reach delay offset jitter
==================================================================
oPPS(0) .PPS. 0 l 3 8 377 0.000 0.001 0.001
+192.9.200.167 .GPS. 1 u 4 64 377 5.201 -0.385 0.381
*192.9.200.168 .GPS. 1 u 33 64 377 0.188 -0.002 0.061
+192.9.200.169 .GPS. 1 u 27 64 377 0.391 -0.004 0.049
-ntp0.uk.uu.net .GPS. 1 u 81 64 376 33.036 4.363 0.563
Two or three hours after disconnecting the .169 antenna:
root@ntp-host:/etc # ntpq -p
remote refid st t when poll reach delay offset jitter
================================================================
oPPS(0) .PPS. 0 l 7 8 377 0.000 -0.001 0.001
+192.9.200.167 .GPS. 1 u 44 64 377 5.162 -0.413 0.018
*192.9.200.168 .GPS. 1 u 38 64 377 0.160 0.000 0.062
+192.9.200.169 .GPS. 1 u 38 64 377 0.408 -0.018 2.813
-ntp0.uk.uu.net .GPS. 1 u 38 64 355 32.479 4.094 0.724
Even though the jitter on .169 has increased, seems that ntp deems
it still within tolerance and continues to use it.
Will leave it running overnight and check again in the
morning...
Chris
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
