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

[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-users Archives ]


It has now been suggested to you at least by two different people-- hook your
system up to the network, and do a timing using a nearby ntp server. That will give you of the order of 10-20us accuracy, and you can see if that
time is the same as your pps time.

I have no idea how accurate gpsd is. I have either written my own interrupt
handler or used the serial pps-ldisc module.




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 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.









Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/