[time-nuts] leontp offset?
Vlad
time at patoka.org
Sat Oct 15 13:40:11 UTC 2016
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
> satellites.
>
> 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
> antenna.
>
> 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 132.163.4.101 2 u 421 1024 373 61.785 2.924
> 0.244
> +four10.gac.edu 216.218.254.202 2 u 1017 1024 377 63.364 -0.137
> 0.381
> -c-73-37-183-90. 142.66.101.13 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
> answer.
>
> I have no relationship with the vendor other than as a satisfied
> customer.
>
> Bob
>
>
>> 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
>> 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, instead maintaining the ~10ms offset.
>>
>> Thoughts?
>>
>> Thanks.
>>
>> Details:
>>
>> 172.17.21.11 is approx 400M away through two Cisco 3750G switches no
>> routing.
>> 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.
--
WBW,
V.P.
More information about the Time-nuts_lists.febo.com
mailing list