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 <un...@physics.ubc.ca> 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 |____ un...@physics.ubc.ca > 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 <un...@physics.ubc.ca> >> 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 |____ >> un...@physics.ubc.ca >> 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 >> <mlich...@redhat.com> 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_AddCookedP >> ulse) >> 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_AccumulateS >> ample) >> 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_DoNewRe >> gression) >> > 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 >> <mlich...@redhat.com> >> > 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. >> >> >> >> >> >>
