f



leontp unexpected offset

Hi all,

I just got a leontp ntp server.

After a week of use I am getting the following ntp -nq output:

$ ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jit=
ter
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
*172.17.21.11    .GPS.            1 u   13   16  377    0.137    0.077   0.=
054             <- Arbiter 1084C GPS Clock
+172.17.21.12    .GPS.            1 u   11   16  377    0.101    0.085   0.=
174             <- Arbiter 1084C GPS Clock
x172.17.21.233   .GPS.            1 u   11   16  377    0.071    9.760   0.=
061            <- LeoNTP

the offset of the leontp device from the other clocks has consistently been=
 in the 9.5 -10.5 range.  since I'm measuring all three sources  from the s=
ame (EL7) computer, I would expect that the offset of the leontp unit to co=
nverge to be in the close neighborhood of the offsets of the arbiters.  It =
has not converged, rather the offset has remained in the ~10ms range.  =20

Thoughts?

Thanks.



Details:

172.17.21.11 is approx 400M away through two Cisco 3750G switches no routin=
g.
172.17.21.12 is in the same rack as the leoNTP unit and plugged into the sa=
me 3750G switch

Antenna location for the .12 arbiter and the leontp are on offset rungs of =
the same tower.  The tower height has a clear horizon to horizon view.  Cab=
le runs are the same (obviously).

I did run with the included puck my south facing office window (rather than=
 the GPS antenna on the tower) for a couple of days when I first got the un=
it.  The offset behaviour was the same.
0
gmx
10/15/2016 12:41:16 AM
comp.protocols.time.ntp 4895 articles. 2 followers. Post Follow

4 Replies
401 Views

Similar Articles

[PageSpeed] 59

Le samedi 15 octobre 2016 02:41:17 UTC+2, gmx.tal...@gmail.com a =C3=A9crit=
=C2=A0:
> Hi all,
>=20
> I just got a leontp ntp server.
>=20
> After a week of use I am getting the following ntp -nq output:
>=20
> $ ntpq -pn
>      remote           refid      st t when poll reach   delay   offset  j=
itter
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
> *172.17.21.11    .GPS.            1 u   13   16  377    0.137    0.077   =
0.054             <- Arbiter 1084C GPS Clock
> +172.17.21.12    .GPS.            1 u   11   16  377    0.101    0.085   =
0.174             <- Arbiter 1084C GPS Clock
> x172.17.21.233   .GPS.            1 u   11   16  377    0.071    9.760   =
0.061            <- LeoNTP
>=20
> the offset of the leontp device from the other clocks has consistently be=
en in the 9.5 -10.5 range.  since I'm measuring all three sources  from the=
 same (EL7) computer, I would expect that the offset of the leontp unit to =
converge to be in the close neighborhood of the offsets of the arbiters.  I=
t has not converged, rather the offset has remained in the ~10ms range.  =
=20
>=20
> Thoughts?
>=20
> Thanks.

Lets compare the PPS output of the Leon and the Arbiter with an oscilloscop=
e to know if the difference comes from the hardware or not.
Best
Jean-Michel
0
girino66
10/15/2016 5:53:49 AM
On 15/10/2016 01:41, gmx.tallahassee@gmail.com wrote:
> Hi all,
>
> I just got a leontp ntp server.
>
> After a week of use I am getting the following ntp -nq output:
>
> $ ntpq -pn
>      remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
> *172.17.21.11    .GPS.            1 u   13   16  377    0.137    0.077   0.054             <- Arbiter 1084C GPS Clock
> +172.17.21.12    .GPS.            1 u   11   16  377    0.101    0.085   0.174             <- Arbiter 1084C GPS Clock
> x172.17.21.233   .GPS.            1 u   11   16  377    0.071    9.760   0.061            <- LeoNTP
>
> the offset of the leontp device from the other clocks has consistently been in the 9.5 -10.5 range.  since I'm measuring all three sources  from the same (EL7) computer, I would expect that the offset of the leontp unit to converge to be in the close neighborhood of the offsets of the arbiters.  It has not converged, rather the offset has remained in the ~10ms range.
>
> Thoughts?
>
> Thanks.

Briefly,

Here is an Intel Atom Linux NTP server fed from a Garmin GPS 18 LVC 
compared against some other devices, where 192.168.0.20 is a LeoNTP:

      remote           refid      st t when poll reach   delay   offset 
jitter
==============================================================================
o127.127.22.0    .kPPS.           0 l    5   16  377    0.000    0.000
0.003
*127.127.28.0    .GPSD.           0 l    6   16  377    0.000   -3.598
0.662
192.168.0.83    .kPPS.           1 u    2   32  377    0.251    0.006
0.017
192.168.0.20    .GPS.            1 u   16   32  377    0.087    0.028
0.002
+192.168.0.1     .kPPS.           1 u    4   32  377    0.161   -0.119
0.022
+192.168.0.7     .kPPS.           1 u   18   32  377    0.196   -0.043
0.027
+192.168.0.8     .kPPS.           1 u    2   32  377    0.160   -0.018
0.139

(sorry about the wrap)

There's no 10 ms offset.  Other devices are: .83 a Raspberry Pi, .1, .7 
..8 Windows kernel-mode PPS synced server.  I would suggest checking your 
Arbiter servers.

Can you check with a 'scope to compare the PPS out out the LeoNTP?  It's 
a 100 ms positive pulse, within about 50 ns of a couple of other GPS/PPS 
devices, and about 200 ns earlier than a Jackson Labs device.

-- 
Cheers,
David
Web: http://www.satsignal.eu
0
David
10/15/2016 9:35:37 AM
Some followup on this.

Short version:  I do -not- think the problem is with the leontp unit.  (act=
ually 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 Ti=
me-Frequency-Deviation-etc GPS clocks are off.  By, oh, around 10 mS. =20

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 c=
ollect the ntpq data with ( ntpq -pn ) has always used the two arbiters for=
 ntp servers, so it's system clock is set to those.=20

 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 in=
dicates something systemic in the way we do things. =20

There were several suggestions on the mailing list to check two pre-settabl=
e 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 powe=
r generation company), so there is a " Frequency Deviation" that the Genera=
tion Control System adjusts for.  I'm wondering if that has introduced a cu=
mulative offset somewhere.  (the indicator to me is the offsets in both arb=
iters are similar).

There was a suggestion on one of the mailing lists to compare the 1PPS outp=
uts of the arbiter and leontp that are in the same location.  I like that i=
dea 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 organize=
d better, probably next week. =20

0
gtx
10/20/2016 1:35:53 AM
More followup:

I set up and configured a brand new xenial box using ntp, and let it run fo=
r a day (approx 7 hours).  Here are the ntpq -p from that:

$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jit=
ter
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
*172.17.21.11    .GPS.            1 u  164  512  377    0.312   -1.531   0.=
325
+172.17.21.12    .GPS.            1 u   60  512  377    0.127   -1.137   0.=
502
x172.17.21.233   .GPS.            1 u   60   64  377    0.126    8.462   0.=
028
 ntp.ubuntu.com  .POOL.          16 p    -   64    0    0.000    0.000   0.=
000
-tssnet1.tss.net 131.107.13.100   2 u   64  512  377   39.496   14.121   0.=
263
+srcf-ntp.stanfo .shm0.           1 u  139  256  377   61.998    6.312   0.=
265
-borris.netwurx. 204.9.54.119     2 u  130  256  377   83.512    9.359   0.=
361
-lithium.constan 18.26.4.105      2 u   22  512  377   98.791    9.172   0.=
709
-alphyn.canonica 132.246.11.231   2 u  247  512  377  110.436    8.303   1.=
354
-chilipepper.can 145.238.203.14   2 u   44  512  377  171.861   11.901   1.=
374

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 simpl=
e and appear to do what they say very well.  'Leo' in the leontp has been v=
ery responsive, over and above, to working with me on this issue, even acqu=
iring and poring over the Arbiter 1084C manual to find potential settings t=
hat can introduce offsets.=20

0
gtx
10/20/2016 1:50:01 AM
Reply: