I'm not too concerned about the accuracy of the PPS. This particular GPS receiver is pretty
high quality. https://learn.adafruit.com/adafruit-ultimate-gps/overview ; It delivers the
NMEA data and the PPS. A number of online resources describing similar projects and the GPSD
Time Service HOWTO page all speak highly of it. I just wasn't sure if there was a way to get
an idea of the clock accuracy using chronyc. Mainly just to be sure I didn't do anything
wrong with the settings.
On Thu, Nov 16, 2017 at 12:57 PM, Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote:
William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology |____ unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/
On Thu, 16 Nov 2017, Joe Smith wrote:
I'm trying to determine the best way to get an idea of my clock
accuracy now that I'm
getting the PPS signals. Is that "chronyc tracking"? When I do
"chronyc sources" or "chronyc
sourcestats" those seem to indicate NMEA offsets that are on the
order of 40-60ms.
NMEA is a prety terrible clock. a) the receiver decodes and composes the nmea
sentances when it is not busy doing something else. The sentences are delivers
at something like 30Kbaud, ( which is about 3000 bytes per second) The sentences
are about 50 bytes long, so just getting in a sentence takes about a 30ms of
a second. And each sentence has a slightly different length so the arrival of
the end of the sentence varies with its length. All of these things mean that
nmea is useless for accruracy better than about 10ms even if you compensate
for the average time delay.
You cannot estimate the accuracy of the PPS from the nmea sentences. It is
like trying to estimate the accuracy of a stopwatch by using a water clock.
debian@beaglebone:~$ chronyc sources
210 Number of sources = 2
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
#? NMEA 0 4 377 14 -59ms[ -59ms]
+/- 107ms
#* PPS 0 4 377 12 -1985ns[-2545ns]
+/- 1792ns
debian@beaglebone:~$ chronyc sourcestats
210 Number of sources = 2
Name/IP Address NP NR Span Frequency Freq Skew
Offset Std Dev
==============================================================================
NMEA 64 29 1009 -8.352 14.888
-48ms 9366us
PPS 10 3 145 -0.000 0.136
-2ns 3981ns
debian@beaglebone:~$ chronyc tracking
Reference ID : 50505300 (PPS)
Stratum : 1
Ref time (UTC) : Thu Nov 16 13:04:35 2017
System time : 0.000000898 seconds slow of NTP time
Last offset : -0.000000564 seconds
RMS offset : 0.000011269 seconds
Frequency : 39.580 ppm fast
Residual freq : -0.000 ppm
Skew : 0.138 ppm
Root delay : 0.000000001 seconds
Root dispersion : 0.000025743 seconds
Update interval : 16.0 seconds
Leap status : Normal
The "chronyc tracking" output seems to indicate (if I'm
understanding the documentation
correctly) that the accuracy is pretty good. Am I interpreting this
correctly?
The PPS accuracy is largely determined by the interrupt handling time, which
is something like a usec. It depends, so that if the the pps comes in when the
computer is reading a disk (which used non-interruptable interrupts) it will
be delayed by many microseconds. But yes, the PPS should be pretty good. as
tracking says it has a rms offset of about 10us. Most of that is delay, so the
accuracy is probably about 10us, The precision is much better, in the hundreds
of ns range.
The only way you could estimate more accurately is to run the PPS to a scope,
and have the system send out a pulse say on the parallel port at a
predetermined time (say 100 usec after the top of the hour using polling of
the clock to say when to send out that pulse) and see what the actual offset
is on the scope.
On Wed, Nov 15, 2017 at 11:48 AM, Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote:
William G. Unruh __| Canadian Institute for|____ Tel:
+1(604)822-3273
Physics&Astronomy _|___ Advanced Research _|____ Fax:
+1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology |____
unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 ____|____ and Gravity ______|_
www.theory.physics.ubc.ca/
On Wed, 15 Nov 2017, Joe Smith wrote:
Thank you so much!! With the lock NMEA it is no longer
ignoring the
pulses. I should be able
to make adjustments to the offset and whatnot to get the clock
accuracy down to where I need
it.
NMEA can never give better than 10s of ms accuracy. The problem is
that when
the gps receiver sends out an NMEA sentence is arbitrary and even
the length
of the sentence is to an extent arbitrary. To get better accuracy,
it is the
PPS that gives it. However the pps conveys only the information of
when the
turnover of the second occurs, not which second that is. That is
what the NMEA
is needed for. (and once the system has that once , it really no
longer needs
the NMEA) since the system clock is sufficiently regular that it can
figure
out which second the pulse belongs to for at least many hours, and
usually for
months.
Thus: chrony is switched on. Chrony uses the NMEA sentences ( or
infomation
from network ntp servers) to get the system clock disciplined to
10's of ms.
The PPS now takes over, and the clock then gets disciplined to
microsecond
accuracy. If the PPS is interrupted for some reason, the system
clock carries
over the seconds information for hours to days until the PPS works
again.
On Wed, Nov 15, 2017 at 2:02 AM, Miroslav Lichvar
<mlichvar@xxxxxxxxxx> wrote:
On Tue, Nov 14, 2017 at 03:45:41PM -0500, Joe Smith
wrote:
> I rebuilt chrony with --enable-debug and ran with -d
-d
Below is some
> output although I'm not 100% sure what it means. Tried
looking at the
> source code to see if I could ascertain the cause but
I was
unable. I let
> it run for a bit and here's some sample output. The
pattern
just seems to
> repeat over and over.
The "sync=0 dist=1.5" part says the system clock is not
synchronized,
which suggests it's not trying to lock to the NMEA
source.
Looking at
your config again, I see now that the PPS refclock is
missing
"lock
NMEA".
Alternatively, you could try to remove noselect from the
NMEA
line, so
chronyd can synchronize the clock to the NMEA source
first and
then
it can switch to PPS.
> 2017-11-14T20:34:22Z
refclock.c:520:(RCL_AddCookedPulse)
refclock pulse
> ignored offset=0.003559951 sync=0 dist=1.500000000
> 2017-11-14T20:34:23Z refclock_shm.c:104:(shm_poll) SHM
sample ignored
> mode=1 count=1202324 valid=0
> 2017-11-14T20:34:23Z
sources.c:356:(SRC_AccumulateSample)
ip=[NMEA]
> t=1510691656.723338336 ofs=0.080481 del=0.200000
disp=0.009623 str=0
> 2017-11-14T20:34:23Z
sourcestats.c:583:(SST_DoNewRegression)
> off=1.007180e-01 freq=6.636850e-05 skew=3.159318e-04
n=16
bs=0 runs=10
> asym=0.000000 arun=0
>
> On Tue, Nov 14, 2017 at 10:36 AM, Miroslav Lichvar
<mlichvar@xxxxxxxxxx>
> wrote:
>
> > On Tue, Nov 14, 2017 at 07:40:33AM -0500, Joe Smith
wrote:
> > > Thank you for the quick response Bill... The PPS
is
coming in on
> > /dev/pps1
> > > which is what I have in the refclock entry in my
chrony.conf file. When
> > run
> > > the cat command corresponding to that device I
get:
> > >
> > > debian@beaglebone:~/ntp-gps-server/pps-overlay$
cat
> > > /sys/devices/virtual/pps/pps1/assert
> > > 1510661769.997836084#571264
> >
> > That looks good. The configuration also looks good.
I
guess the only
> > thing that could be wrong is the offset value on the
SHM
line. Does
> > the machine have an internet connection? It might
help if
you could
> > configure it with an NTP server and remove the lock
option
from PPS to
> > see if it works that way and to see if the offset of
the
NMEA source
> > needs to be adjusted.
> >
> > If that doesn't work, recompiling chrony with debug
support
> > (--enable-debug) and running chronyd with -d -d
should
show why it's
> > ignoring the PPS samples.