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

Andy Harrison aharrison+ntp at gmail.com
Mon Aug 5 14:23:10 UTC 2019

Just wanted to say thanks to all the responders to my thread.  Just to
close the loop, I was obviously wrong in my assessment.

Since I was at the point where I was thinking it might be a bug in ntpd, I
started from scratch and began the steps to reproduce and document my
results from the ground up.  In doing so, I figure what I had done was to
leave the Symmetricom in the wrong mode (SSU mode vs. PRR mode) while I was
doing my testing and packet tracing.  I twiddled so many knobs on that
thing I obviously lost track.

So, to summarize, when the Symmetricom is in PRR mode, even when there is a
problem with the GPS input, it will intentionally keep on advertising
itself as a stratum 1 outwardly, falling back to holdover mode using its
internal oscillator for its time source.  Since that oscillator keeps
reasonably high quality time (we don't have the rubidium oscillator, but
still, it keeps decent time), I can only imagine how long it would take for
it to be perceived by the clients as weak enough for them to switch to
another source.

I've written a health check script that will connect in, look for alarms
and quality level and such, then on discovering any problems, knocks the
Symmetricom out of PRR mode into SSU mode and disables the GPS input.  Once
that happens, the Symmetricom stops reporting time and its stratum level in
its responses, then, as expected, the reachability drops and clients select
another source.

Given this, I hesitate to call this a bug in ntpd.  I mean, _maybe_ it'd be
nice if it handled a source ceasing to report it's stratum level, but I
think it should be the Symmetricom that reports it's stratum level
correctly.  Since this is an EOL device, I'm not holding my breath for any
firmware updates any time soon.

I appreciate you all taking the time and your informative responses.



More information about the questions mailing list