[time-nuts] leontp offset
gtx.tallahassee at gmail.com
Thu Oct 20 12:21:33 EDT 2016
Some followup on this.
Short version: I do -not- think the problem is with the leontp unit.
(actually I never did. I figured there was something I was doing wrong).
Not quite so short version: I think that both our very expensive Arbiter
Time-Frequency-Deviation-etc GPS clocks are off. By, oh, around 10 mS.
This was determined by comparing the three "internal" (two Arbiters and the
leontp) ntpq -p outputs to 6 'external' (internet accessible) ntp servers
and letting them all run for a workday. The box (EL7) that was using to
collect the ntpq data with ( ntpq -pn ) has always used the two arbiters
for ntp servers, so it's system clock is set to those.
All the other "external" clocks had offsets in the 8-12 mS, close to what
the leontp was coming in at. The arbiters were less than 800 uS offset.
full disclosure: there were a couple of outlier external clocks I threw
out, one with a 38 ms offset and the other with a 112 ms offset).
What's worrying is that both arbiters off by the same-ish amount. This
indicates something systemic in the way we do things.
There were several suggestions on the mailing list to check two
pre-settable offsets in the arbiters. These are set at:
Cable Length: 60nS
Programmable Offset: 00000000
However, these Arbiters are also used for Grid Frequency (this is at a
power generation company), so there is a " Frequency Deviation" that the
Generation Control System adjusts for. I'm wondering if that has
introduced a cumulative offset somewhere. (the indicator to me is the
offsets in both arbiters are similar).
There was a suggestion on one of the mailing lists to compare the 1PPS
outputs of the arbiter and leontp that are in the same location. I like
that idea and will do it when I find my oscilloscope (Or, more accurately,
dig it out of the storage closet out in the warm storage building).
I will be contacting Arbiter directly as soon as I get my findings
organized better, probably next week.
I set up and configured a brand new xenial box using ntp, and let it run
for a day (approx 7 hours). Here are the ntpq -p from that:
$ ntpq -p
remote refid st t when poll reach delay offset
*172.17.21.11 .GPS. 1 u 164 512 377 0.312 -1.531
+172.17.21.12 .GPS. 1 u 60 512 377 0.127 -1.137
x172.17.21.233 .GPS. 1 u 60 64 377 0.126 8.462
ntp.ubuntu.com .POOL. 16 p - 64 0 0.000 0.000
-tssnet1.tss.net 184.108.40.206 2 u 64 512 377 39.496 14.121
+srcf-ntp.stanfo .shm0. 1 u 139 256 377 61.998 6.312
-borris.netwurx. 220.127.116.11 2 u 130 256 377 83.512 9.359
-lithium.constan 18.104.22.168 2 u 22 512 377 98.791 9.172
-alphyn.canonica 22.214.171.124 2 u 247 512 377 110.436 8.303
-chilipepper.can 126.96.36.199 2 u 44 512 377 171.861 11.901
the .11 and .12 units are the Arbiters. The .233 is the leontp unit. This
is two days in a row, on two separate boxes (one a fresh install) that the
arbiters are showing up differently than the rough consensus of others.
As a side note, I really like these leontp units. They are small and
simple and appear to do what they say very well. 'Leo' in the leontp has
been very responsive, over and above, to working with me on this issue,
even acquiring and poring over the Arbiter 1084C manual to find potential
settings that can introduce offsets.
I will not have a chance to explore some of these Arbiter settings until
next week. Arbiters are something of a pain to configure. Arbiter has
some new models in their pipeline that use a web based interface for
settings but those have been in the 'real soon now' stage for over a year.
More information about the time-nuts