[LinuxPPS] PC Clock Offset

Fri Jun 12 00:13:57 CEST 2009

On Thursday 11 June 2009 11:13:57 am Andrew Hills wrote:
> Hal V. Engel wrote:
> > I am not sure why you are seeing this.  A well setup Oncore on a LinuxPPS
> > machine should see offsets that approach the microsecond range.  You
> > didn't include your /etc/ntp.conf or your /etc/ntp.oncore* files so it is
> > difficult for us to tell what you may have done.  Are you using the
> > correct edge of the pulse?  If the PPS line is a direct ttl connection
> > from the GPS to the DCD pin then you should be using the ASSERT edge but
> > if this is inverted you should be using CLEAR.  If you are using the
> > wrong edge then it should be off by about 200ms.
>
> I've attached my ntp.conf and ntp.oncore.0 files (please ignore the
> strange naming scheme). I believe I should be using ASSERT, but I'm
> really only basing that off of the knowledge that the person who built
> the system had ASSERT rather than CLEAR in his ntp.oncore.0 file. I will
> experiment with CLEAR later today.

These look OK.

>
> > Also when the serial "time" information arrives from the GPS is not
> > deterministic.  What is deterministic is when the PPS pulse arrives.  In
> > other words the time data transmitted by the GPS is to number the seconds
> > and is always after the top of the second being numbered (actually I
> > think it is after the PPS pulse has completed but I may be wrong).  The
> > PPS is to signal the exact top of the second (+- sawtooth).
>
> That makes much more sense. I suppose I was confused about the PPS
> method of timekeeping. Thanks.
>
> > In
> > any case you can NOT use the serial time data for anything other than for
> > numbering the seconds since it is not transmitted at the exact top of the
> > second and the Motorola specs say that the timing of this data is not
> > guarantied and it should not be used for anything other than numbering
> > the seconds.
>
> Well, I'm pretty sure that's my error, then. Is there another way to
> determine the offset between my PC clock and the GPS clock?

NTP does that for you so I am not sure why you wrote a utility to do this.  
Just set the Oncore as your prefer peer and then you can query this with any 
of the following:

$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
============================================
*GPS_ONCORE(0)   .GPS.            0 l   12   16  377    0.000    0.000   0.001

$ ntptime
ntp_gettime() returns code 0 (OK)
  time cddbcad5.d370367c  Thu, Jun 11 2009 11:26:29.825, (.825931524),
  maximum error 4479 us, estimated error 0 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 0.079 us, frequency -39.026 ppm, interval 1 s,
  maximum error 4479 us, estimated error 0 us,
  status 0x2001 (PLL,NANO),
  time constant 4, precision 0.001 us, tolerance 500 ppm,

$ ntpq -c rv
associd=0 status=0464 leap_none, sync_uhf_radio, 6 events, freq_mode,
version="ntpd 4.2.4p7 at 1.1607-o Fri May 22 17:24:12 UTC 2009 (1)",
processor="x86_64", system="Linux/2.6.26.8-rt12pps-rt", leap=00,
stratum=1, precision=-20, rootdelay=0.000, rootdispersion=0.396,
peer=6429, refid=GPS,
reftime=cddbce58.367b2686  Thu, Jun 11 2009 11:41:28.212, poll=4,
clock=cddbce62.d9521792  Thu, Jun 11 2009 11:41:38.848, state=4,
offset=0.000, frequency=-39.046, jitter=0.001, noise=0.001,
stability=0.000, tai=0

$ ntpq -c as

ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1  6429  9624   yes   yes  none  sys.peer   reachable  2

$ ntpq -c "rv 6429"
associd=6429 status=9624 conf, reach, sel_sys.peer, 2 events, reachable,
srcadr=GPS_ONCORE(0), srcport=123, dstadr=127.0.0.1, dstport=123,
leap=00, stratum=0, precision=-26, rootdelay=0.000,
rootdispersion=0.000, refid=GPS, reach=377, unreach=0, hmode=3, pmode=4,
hpoll=4, ppoll=4, flash=00 ok, keyid=0, ttl=0, offset=0.000,
delay=0.000, dispersion=0.247, jitter=0.001,
reftime=cddbce7a.00000033  Thu, Jun 11 2009 11:42:02.000,
org=cddbce7a.00000033  Thu, Jun 11 2009 11:42:02.000,
rec=cddbce7a.39114173  Thu, Jun 11 2009 11:42:02.222,
xmt=cddbce7a.2cb0446c  Thu, Jun 11 2009 11:42:02.174,
filtdelay=     0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00,
filtoffset=    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00,
filtdisp=      0.00    0.26    0.51    0.77    1.04    1.26    1.49    1.73

The above are examples from a well setup system with an Oncore UT+ ref clock.  
Even though the above offset is only 79 nanoseconds the actual offset is 
likely more since I have not tried to compensate for the latency of the PPS 
interrupt handler which is probably on the order of several microseconds or 
the delay in my serial cable which is probably around 9ns.

One other thing you can do for testing is to add some additional external 
servers so that you can compare what ntp is seeing from those sources compared 
to the Oncore.  When testing that way here I see these external servers having 
offsets of 1ms to 3ms when the Oncore offset is close to 1us.  The offsets for 
these (well chosen) external servers is likely because my network connection 
is asynchronous (fast down link slower up link).

Hal