Re: [chrony-users] GPS / Chrony NTP server config questions

[ Thread Index | Date Index | More Archives ]

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.

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?

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 ______|_

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

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

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

      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.

Mail converted by MHonArc 2.6.19+