[ntp:questions] symmetricom tp1100 stratum and leap indicator behavior

Chris xxx.syseng.yyy at gfsys.co.uk
Fri Aug 2 17:47:56 UTC 2019


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 at 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 at 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



More information about the questions mailing list