Yo David!
On Fri, 21 Oct 2016 09:00:33 +0100
"David J Taylor" wrote:
> I set up and configured a brand new xenial box using ntp, and let it
> run for a day (approx 7 hours).
NTPsec, or NTp Classic?
> remote refid st t when poll reach delay offset
> *172.17.21.11.GPS
> Le 20 oct. 2016 à 22:06, Hal Murray a écrit :
>
>
>> 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).
>
> That's not uncommon. It happens more often when the server is farther away
> and there are m
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
jitter
> 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).
That's not uncommon. It happens more often when the server is farther away
and there are more opportunities for strange network routing.
The NIST server
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
When I read "fatPPS" I thought of the same thing. The best use of a pulse
stretcher is to verify you are interrupting on the correct edge because a
wrong edge error will be obvious if the pulse is wide.
On Sat, Oct 15, 2016 at 7:36 AM, Bob Camp wrote:
> Hi
>
> The 10 ms offset *is* suspiciousl
Hi
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.
Bob
> On Oct 15, 2016, at 9:40 AM, Vlad wrote:
>
>
>
> I am wandering if it will be the same results without 'FatPPS'. In my Lab I
> was a
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.
Check the Arbiter for anomalous "Cable Delay" or "Clock Offset" settings.
Maybe they accidentally got set to 999ns instead of zero.
Page 38 in this manual:
http://www.arbiter.com/files/product-attachments/1084_manual.pdf
Tim N3QE
On Fri, Oct 14, 2016 at 8:31 PM, gmx tallahassee
wrote:
> Hi
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
==
I think the best assumption you can make is to take it at face value.
It looks like leontp is about 10ms "off" from your local time. One
of you is wrong and at this point there is no way to know who is wrong
But of course you appear to be getting time closer to arbiter
So either arbiter or leon
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
gmx.tallahas...@gmail.com said:
> 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 neighbo
13 matches
Mail list logo
