[time-nuts] leontp offset?
kb8tq at n1k.org
Sat Oct 15 10:36:28 EDT 2016
The 10 ms offset *is* suspiciously close to what you would get with a 10 ms pulse stretcher
*and* a setup that is triggering on the wrong edge.
> On Oct 15, 2016, at 9:40 AM, Vlad <time at patoka.org> wrote:
> I am wandering if it will be the same results without 'FatPPS'. In my Lab I was able to use T-Bolt 1PPS through TADD-3 (not from RS2323). Works stable.
> I am using 'chrony' though
> 210 Number of sources = 5
> .- Number of sample points in measurement set.
> / .- Number of residual runs with same sign.
> | / .- Length of measurement set (time).
> | | / .- Est. clock freq error (ppm).
> | | | / .- Est. error in freq.
> | | | | / .- Est. offset.
> | | | | | | On the -.
> | | | | | | samples. \
> | | | | | | |
> Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
> PPS0 19 10 291 -0.000 0.003 -1ns 293ns
> ntp2.torix.ca 10 7 154m +0.848 0.256 +4251us 459us
> time.sidereal.ca 9 5 137m +0.311 0.539 -3996us 837us
> S0106c04a00f34a5d.vc.shaw 40 18 11h -0.036 0.050 -5995us 1009us
> omega.goholdings.ca 58 29 16h -0.040 0.036 +5987us 1345us
> On 2016-10-15 01:17, Bob wrote:
>> Here is a BSD computer running ntpd, configured with hardware serial
>> port attached GPS, PPS through FatPPS into the serial port seen as
>> GPS_NMEA below, along with the two LeoNTP servers at 192.168.20.5 and
>> 192.168.20.6, offset and jitter appear reasonable, as expected on a
>> LAN, and I've seen no anomalies over the past month.
>> remote refid st t when poll reach delay offset jitter
>> oGPS_NMEA(0) .GPS. 0 l 20 16 377 0.000 0.002
>> 0.001 <- BSD+PPS
>> +192.168.20.5 .GPS. 1 u 24 64 377 0.162 -0.011
>> 0.006 <- LeoNTP #1
>> +192.168.20.6 .GPS. 1 u 44 64 377 0.159 -0.009
>> 0.004 <- LeoNTP #2
>> The three devices above have separate GPS antennas installed within a
>> couple meters of each other, all three see between 10 and 12
>> A couple weeks ago I also used an HP 5334B to compare each LeoNTP PPS
>> to a TVB screened T-Bolt PPS, the T-Bolt was configured with LH
>> extended location calibration and in over-determined time mode, T-bolt
>> sees 7 or 8 satellites. Each LeoNTP 1PPS BNC output agreed with the
>> T-Bolt 1PPS to within some tens of nanoseconds over a 30 hour run.
>> The LeoNTP and T-Bolt shared a Microsemi gps splitter and the same
>> After reading your email, as a final sanity check we just set up a
>> Linux ntpd configured with both LeoNTP servers along with four random
>> us ntp pool servers. After an hour here is ntpq -p.
>> remote refid st t when poll reach delay offset jitter
>> +192.168.20.5 .GPS. 1 u 46 64 377 0.604 -0.059 0.123
>> *192.168.20.6 .GPS. 1 u 40 64 377 0.602 -0.050 0.116
>> -x.ns.gin.ntt.ne 249.224.99.213 2 u 528 1024 377 12.232 2.023 10.209
>> xclockb.ntpjs.or 188.8.131.52 2 u 421 1024 373 61.785 2.924 0.244
>> +four10.gac.edu 184.108.40.206 2 u 1017 1024 377 63.364 -0.137 0.381
>> -c-73-37-183-90. 220.127.116.11 2 u 418 1024 377 64.903 1.928 2.507
>> In the above, 192.168.20.5 and 192.168.20.6 are each LeoNTP, they
>> agree with the four pool servers as nicely as can be expected with a
>> cable modem connection.
>> Summary: I do not see any issues with the LeoNTP servers, both
>> devices worked as expected. LeoNTP is also by far the friendliest
>> commercial NTP server I've ever configured, the human interface is
>> well thought out.
>> As Hal suggested, perhaps there is some systematic configuration issue
>> with your other pair of clocks? I keep a $40 Adafruit Ultimate GPS
>> with PPS output and little puck antenna, for the sort of situation you
>> see, it powers up indoors in 60 seconds and its PPS into ntpd would
>> let you have a 3rd clock if using internet servers doesn't get you an
>> I have no relationship with the vendor other than as a satisfied customer.
>>> On Oct 14, 2016, at 5:31 PM, gmx tallahassee <gmx.tallahassee at gmail.com> wrote:
>>> Hi all,
>>> I'm checking out the leontp ntp time server (leontp.com). After a week of
>>> use I am getting the following ntp -q output:
>>> $ ntpq -pn
>>> remote refid st t when poll reach delay offset
>>> *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, instead maintaining the ~10ms offset.
>>> 172.17.21.11 is approx 400M away through two Cisco 3750G switches no
>>> 172.17.21.12 is in the same rack as the leoNTP unit and plugged into the
>>> same 3750G switch
>>> Antenna location for the .12 arbiter and the leontp is on the same rung of
>>> the same tower. Tower has clear horizon to horizon view. cable runs are
>>> the same (obviously).
>>> I did run with the included puck in my south facing office window (rather
>>> than the GPS antenna on the tower) for a couple of days when I first got
>>> the unit. The offset behaviour was the same.
>>> time-nuts mailing list -- time-nuts at febo.com
>>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>> and follow the instructions there.
>> time-nuts mailing list -- time-nuts at febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
More information about the time-nuts