On 06/10/21 03:17, William Unruh wrote:
On 2021-06-09, chris<chris-nos...@tridac.net>  wrote:
On 06/09/21 22:00, ProGeek wrote:
On Wednesday, June 9, 2021 at 6:56:04 PM UTC+3, chris wrote:
On 06/08/21 20:42, Andreas Mattheiss wrote:
Hello,

just as additional source of information: I have a similar setup here
(ublox PPS into a proper serial port of a PC) and I see a stable offset of
-3 ms to 3 servers on the net (-3 ms to any of them). I'm using ntpd
though.

Regards
Andreas

This is what I see at the ntp host here:

chris@ntp-host:~ % ntpq -pn
remote refid st t when poll reach delay offset jitter
======================================================================
o127.127.22.0 .PPS. 0 l 1 8 377 0.000 0.000 0.001
+192.9.200.168 .GPS. 1 u 10 64 377 0.193 0.001 0.054
*192.9.200.169 .GPS. 1 u 7 64 377 0.354 0.008 0.046

Using mini pc host with two network interfaces, internet and internal
network facing. FreeBSD 12 with ttl pps into the serial port dcd line
via a ttl to rs232 converter...

Chris
this is what i see on sourcestats:

210 Number of sources = 7
                               .- 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
==============================================================================
GPS0                       12   6   176    -29.089     42.914  -8857us  1790us
SHM1                       12   7   178     +0.000      0.010   -530ms   435ns
PPS0                       12   7   178     +0.001      0.011     +3ns   445ns
blackmamba-g0.eff.ro        2   0    77     -0.005   2000.000   +501ms  4000ms
188.213.49.35               9   6   184     -0.748     21.608   +492ms   721us
time.cloudflare.com         6   4    81     +1.162      9.574   +500ms    72us
time.cloudflare.com        14  11   168     +0.502      0.939   +500ms    42us

if i get the results from PPS0 the offset is low, but is still reported high. 
and also correspond with the external time servers.

my settings are like this:

# SHM(0), gpsd: NMEA data from shared memory provided by gpsd
refclock SHM 0 refid GPS0 poll 4 precision 1e-1 trust noselect offset 0.646

# SHM(1), gpsd: PPS0 data from shared memory provided by gpsd
refclock SHM 1 refid SHM1 poll 4 precision 1e-3 lock GPS0 trust noselect offset 
0.5300

# PPS: /dev/pps0: Kernel-mode PPS ref-clock for the precise seconds
refclock PPS /dev/pps0 refid PPS0 poll 4 precision 1e-7 lock GPS0 trust prefer 
delay 0.50

something is off but i can't pinpoint what

Just using a standard ntpd here, as it's more than adequate for the
task, with minimum granularity in microseconds. Does look like there
is something seriously wrong, as the gps is 8mS out, and should be
fractions of a mS if working right.

No, it should not be. GPS is the NMEA sentences from the gps device. It
is usually delayed by from .1 to .3 sec. Ie, it keeps terrible time.
It is the PPS that is spot on to the ns level.

Well, we know that, but if there is an available PPS, that becomes
the primary reference for the local system.


What I would try is to strip out all except the pps and gps sources
and see what the offset looks like. Also, please post the ntpd.conf

He did post the sentences from the chrony.conf file ( the equivalent to
the ntpd.conf file) and they are weird.

Not familar with chrony, but why not go back to basics, run a stock
ntpd, which works out of the box. Why make life difficult, when ntpd has more than adequate precision for the task ?. Experiment with other
solutions once the basics are known working and experience gained.


file, as that can skew everything if misconfigured. Finally, check
the polarity of the pps signal, as the ~500mS offset for several
sources, (0.5 x 1sec), suggest pps input needs an inversion, but the
ntp.conf file has a line to define that...

It may be that he has chosen the wrong polarity, but I suspect he has
simply chosen the wrong options (the delay and offset options).


If the 1pps signal has a 50% m/s ratio, then the ~0.5second offset on
the external sources is a glaring indicator of wrong polarity...


_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Reply via email to