[lug] NTP with a GPS

[George Sexton]

> -----Original Message-----
> From: lug-bounces at lug.boulder.co.us [mailto:lug-
> bounces at lug.boulder.co.us] On Behalf Of Gary Hodges
> Sent: Monday, April 25, 2011 3:40 PM
> To: Boulder (Colorado) Linux Users Group -- General Mailing List
> Subject: Re: [lug] NTP with a GPS
> 
> On 04/25/2011 02:11 PM, George Sexton wrote:
> > I hate to say it, but you really have the wrong unit. If you want
> time from
> > a GPS unit you needs PPS output. Without PPS, you're only going to
> get +/-
> > several hundred milliseconds. There's just too much jitter in the
> arrival of
> > the timing message without PPS. This is why your NTP daemon is
> throwing out
> > both units.
> >
> > You should use a Garmin 16X because it has PPS output.
> 
> I spoke/posted from faulty memory.  I do have the 16X.  Figuring out
> the
> PPS part is on the list of to do items.  I also have the HVC model.

Here's a little info.

On my system, I have PPS connected to DCD on the serial port.

I'm using gpsd version 2.40DEV. You need at least this version or higher
because there's a bug in lower versions that has to do with timing between
the PPS and the NMEA sentences.

I've had a few problems with GPSD/NTP interaction. The problem seems to be
if GPSD starts first, it creates shared memory regions that NTP can't
access. I looked at this briefly, and I see GPSD is running as Nobody, while
I think NTP is running as "ntp". My manual workaround is to manually start
GPSD after NTP has started. When I upgrade my distribution I'll try to sort
this out.

Finally, add it to ntp.conf

server 127.127.28.1 prefer minpoll 4 maxpoll 4
fudge 127.127.28.1 refid PPS time1 -0.009

I chose the 9 millisecond offset from looking at my offset from NIST

> 
> Gary
> 
> > Here's the output of ntpq -p for mine:
> >
> >       remote           refid      st t when poll reach   delay
> offset
> > jitter
> >
> =======================================================================
> =====
> > ==
> > +time-B.timefreq .ACTS.           1 u   21  512  377   35.680   -
> 0.237
> > 0.545
> > +time-A.timefreq .ACTS.           1 u  480 1024  377   36.306   -
> 0.555
> > 0.648
> > -utcnist2.colora .ACTS.           1 u   75  512  377   36.542
> 1.298
> > 1.180
> > -masql.mailarmor 192.43.244.18    2 u   31   64  377   14.540
> 6.851
> > 2.345
> > *SHM(1)          .PPS.            0 l   16   16  377    0.000
> 0.002
> > 0.003
> >
> >
> > The offset and Jitter for PPS is .002 milliseconds, or 2
> microseconds.
> > Maximum offset and jitter is generally around 10 microseconds.
> >
> > If it were me, I would use one unit with PPS.
> >
> > Here's a pretty good reference.
> >
> > http://time.qnan.org/
> >
> >
> > The author used a 18LVC. I chose to use a 16x so that I could use a
> higher
> > voltage power supply and not worry about voltage drop on a longer
> cable run.
> >
> >
> > George Sexton
> > MH Software, Inc.
> > 303 438-9585
> > www.mhsoftware.com
> >
> >
> >> -----Original Message-----
> >> From: lug-bounces at lug.boulder.co.us [mailto:lug-
> >> bounces at lug.boulder.co.us] On Behalf Of Gary Hodges
> >> Sent: Monday, April 25, 2011 12:45 PM
> >> To: Boulder (Colorado) Linux Users Group -- General Mailing List
> >> Subject: [lug] NTP with a GPS
> >>
> >> I've been doing some testing, and have actually deployed at a couple
> >> sites, a Garmin GPS 18x to keep the time set for one computer.
> >> Everything was going OK, until the most recent case.  At this site I
> >> have the computer set up on the network, and had been keeping time
> set
> >> with NTP to another machine that uses GPS.  I don't know the
> physical
> >> location of that machine, or anything about it actually.  Due to
> >> network
> >> rules, that was the only time server available to me.  I hooked up a
> >> GPS
> >> to my machine, figuring two is better than one, but I may have
> invoked
> >> the adage "One clock is correct.  With two both are wrong."
> >>
> >> I logged on today to see how my new set up was working, and I found
> >> that
> >> both time servers had an "x" preceding them when querying with  ntpq
> -
> >> p.
> >>
> >>        remote           refid      st t when poll reach   delay
> offset
> >>    jitter
> >>
> =======================================================================
> >> =======
> >> xSHM(0)          .GPSe.           0 l    8   16  377    0.000  -
> 65.986
> >> 29.232
> >> x192.168.241.135 .GPS.            1 u  255  256  377    3.979  -
> 11.009
> >> 18.461
> >>
> >> My GPS is noted by GPSe.  If I comment either one out in the
> ntp.conf
> >> file, ntp works as expected.  That is I get an "*" preceding the
> time
> >> server.  My assumption is that with a stratum 0 and 1 server
> available,
> >> but with the difference in the offsets too great, it concludes
> neither
> >> can be trusted and both are stamped with x.
> >>
> >> I have played around with the time1 parameter in the ntp.conf file
> to
> >> bring the offsets closer together, and that seems to work.
> >>
> >>        remote           refid      st t when poll reach   delay
> offset
> >>    jitter
> >>
> =======================================================================
> >> =======
> >> *SHM(0)          .GPSe.           0 l    2   16  377    0.000  -
> 23.996
> >> 14.344
> >>    SHM(1)          .GPSe.           0 l    -   16    0    0.000
> 0.000
> >>     0.001
> >> +192.168.241.135 .GPS.            1 u  252  256  177    4.132  -
> 27.314
> >> 12.543
> >>
> >> Here it has my GPS as the preferred time server, and the other is
> >> indicated by the + as a high quality replacement candidate.  Even
> >> though
> >> I seem to have made it work, going forward I'm considering
> commenting
> >> one out as there appears to be potential issues with using two time
> >> servers.
> >>
> >> Is anyone here able to verify or refute my assumption about using
> two
> >> time servers?  Accuracy to within one second is more than sufficient
> >> for
> >> my needs.
> >>


George Sexton
MH Software, Inc.
303 438-9585
www.mhsoftware.com