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

Terje Mathisen terje.mathisen at tmsw.no
Thu Aug 1 15:13:18 UTC 2019


Chris wrote:
> On 08/01/19 12:43, Terje Mathisen wrote:
>> Chris wrote:
>>> On 07/31/19 20:10, Andrew Harrison wrote:
>>>> The backstory...  I've been tasked with deploying a pair of
>>>> Symmetricom TP1100 Time Providers with GPS antennae as the official
>>>> time source for the company (replacing an ancient server with a
>>>> Meinberg card in it).  My company actually purchased the Symmetricoms
>>>> a few years ago, but they never got around to putting them in
>>>> production.  No one was able or willing to put in the time to get
>>>> them going.  I started working at the company recently and they gave
>>>> the project to me.
>>>>
>>>> I've got them up and running and my test ntp client (my Linux
>>>> workstation running ntp 4.2.8p12) can pull time from them just fine.
>>>>
>>>> Now for the hard part.  What we want to happen is that if the GPS of
>>>> the primary Symmetricom goes offline, we want the clients to start
>>>> getting time from the backup unit.
>>>>
>>>> Ideally what would happen is the GPS goes offline, the Symmetricom
>>>> would set itself to a higher stratum level and the clients abandon it
>>>> for the device that has the better stratum, but this is not what
>>>> happens.
>>>>
>>>> I had to use Wireshark to see that instead, when the GPS goes
>>>> offline, the Symmetricom stops advertising a stratum level (Wireshark
>>>> shows "unspecified or invalid") while the leap indicator shows "clock
>>>> unsynchronized" (3 I think it was).  (When I enable the GPS again,
>>>> Wireshark shows the stratum level coming through as 1 and leap
>>>> indicator shows 0 "no warning".)
>>>>
>>>> On my workstation test client, ntp apparently doesn't know what to do
>>>> when a time source stops indicating its stratum level so it keeps
>>>> right on showing stratum 1 in ntpq output even though Wireshark
>>>> clearly shows the packets coming through with stratum level
>>>> "unspecified or invalid".
>>>>
>>>> So, my question is, can I configure ntp in such a way that it
>>>> responds to either a lack of advertised stratum or a leap warning
>>>> indicator greater than 0?
>>>>
>>>>
>>>> Thanks!
>>>>
>>>>
>>>
>>>
>>> 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.
>>> 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 ran the ntp setup for Norway's largest multinational corporation for
>> 20+ years, my final setup used dedicated TrueTime/Symmetricom/Meinberg
>> gps-based servers in 3 main locations, augmented with radio-based clocks
>> in a couple more as well as several hand-made FreeBSD servers using
>> Oncore and SURE evaluation boards with timing gps receivers.
> 
> Sounds like fun.
> 
>>
>> All these primary sources were used as references for a second layer of
>> dedicated Stratum 2 servers, two in each of those 3 main geographical
>> centers, and with identical/symmetrical conf files. The latter works
>> because an ntpd server automatically omits any circular reference, to
>> itself or another source.
>>
>> Finally, every single client machine capable of running the full ntpd
>> stack was configured to use all 6 Stratum 2 servers as their reference,
>> this provided enough redundancy that we never suffered any visible
>> hickups even when we passed through the GPS week rollover or when an
>> individual reference server lost a leap second event.
>>
>> Except for the hardware ref servers, this was all effectively close to
>> zero cost, only some labor hours.
>>
> Not so ambitious, but trying to do the same sort of thing in the
> experimental setup here. A bit of a newby with ntp, but have used
> ntp on machines for years. Also gps based 10MHz frequency
> standards for the lab test gear. Consider redundancy pretty much
> essential and even with a set of local hardware time servers,
> would always include some ntp pool entries, if only as a sanity

Absolutely! We had both a generic "pool" command to query internet 
servers, as well as peering agreements with multiple other S1 servers.

> check for the local hardware. If you work it through another host,
> ntp should do all the hard work for you anyway, the algorithms
> deciding which are the most accurate subset and automatically
> rejecting outliers.
> 
> One thing from the op's post is the apparent reversion to
> stratum invalid, which suggests an out of lock gps condition.

This looks like a driver/gps mismatch, i.e. the driver should revert to 
status non-sync and drop stratum to 15/16 unless the unit has a very 
good Rb/TCXO local oscillator providing configurable holdover in case of 
gps loss. In the latter case the dispersion value should/will go up as 
the time of holdover increases, eventually letting the clients decide 
that another server is better.

> What i've found with older gps receivers is that the antenna
> often needs a clear view of the sky for best performance, or
> even to lock at all, so a window ledge antenna solution may not
> be good enough...

There has been a huge shift here, from the original 2-6 channel 
receivers, via the classic 12-channel (i.e. Garmin puck with partly 
documented pseudo-range capabilities) and the Oncore timing-optimized 
models, to the current situation where all the channels are software 
defined so only your power budget limits how many you can track or 
search for simultaneously.

With the Oncore and few others, you would place them in Zero-D mode, by 
telling them in the config file exactly where they were located, so that 
tracking a single sat was sufficient to provide sub-us timing precision.

With a modern multi-GNSS receiver you can track both the direct wave and 
arbitrary reflection, so just a small glimpse of the sky can provide a 
very good timing fix.

Terje

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"



More information about the questions mailing list