[lug] NTP with a GPS

[Gary Hodges]

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.

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.
>>
>> _______________________________________________
>> Web Page:  http://lug.boulder.co.us
>> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
>> Join us on IRC: irc.hackingsociety.org port=6667
>> channel=#hackingsociety
>
>
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
>