[time-nuts] leontp offset

gtx tallahassee 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.

More followup:

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

*    .GPS.            1 u  164  512  377    0.312   -1.531
+    .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   2 u   64  512  377   39.496   14.121
+srcf-ntp.stanfo .shm0.           1 u  139  256  377   61.998    6.312
-borris.netwurx.     2 u  130  256  377   83.512    9.359
-lithium.constan      2 u   22  512  377   98.791    9.172
-alphyn.canonica   2 u  247  512  377  110.436    8.303
-chilipepper.can   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 mailing list