Jason wrote:
> All,
>
> This is my first attempt to build an 'accurate' GPS-based time server.
> There is no Internet connectivity, so the GPS (and it's PPS) are the
> only sources of timing data.
>
> I'm using a San Jose Navigation FV-M8 [1]. As a GPS, it works great. I
> piped the PPS signal to the CTS line (gpsd-2.36 supports this) and with
> a minor tweak to gpsd (until I can find the sentence to change the pulse
> length), gpsd finds the pulse and hands everything off to ntpd as per
> the gpsd man page [2].
>
> Watching ntpd from 'ntpq -p' appears to work as expected. When the
> offset (SHM(0), average gps) is less than 1 second, gpsd sends the
> appropriate info to SHM(1) (gps pps), which ntpd uses ('ntpq -p' SHM(1)
> reach changes from 0 to positive values).
>
> Basically, I think I have the hardware set up right. However, I left it
> running over night because I kept seeing the following:
>
> # watch -n3 ntpq -p
> remote refid st t when poll reach delay offset
> jitter
> ==============================================================================
> *SHM(0) .GPS. 0 l - 16 377 0.000 1831.01
> 771.100
> SHM(1) .GPS1. 0 l 86 16 40 0.000 0.000
> 0.004
>
> Sorry if it's line wrapped. The offset of SHM(0) will wander from less
> than a second (< 1000.00) to around 8 seconds. Each time it gets close
> (< 1000.00) the numbers for SHM(1) start changing, which tells me it's
> trying to use the PPS to pull it in tight. But, then SHM(0) will wander
> off again.
>
> What is normal? How long should it take a stand alone GPS time server
> to lock in? What should I tweak to fix this? Any insight would be
> appreciated.
>
> /etc/ntp.conf appended.
>
> Note: I tried deleting the drift file, and changing the time1 value, to
> no avail. (I'm shooting in the dark with that one ;-) )
>
> thx,
>
> Jason.
>
>
> [1] - http://www.sanav.com/gps_engine_board/FV-M8.htm
> [2] - http://gpsd.berlios.de/gpsd.html
> Section: "Use with NTP"
>
>
> ######## /etc/ntp.conf ###############################################
> [snipped commented out stuff]
>
> # Added 20080122 to sync to GPS
> server 127.127.28.0 minpoll 4 maxpoll 4
> #fudge 127.127.28.0 time1 0.420 refid GPS
> fudge 127.127.28.0 time1 0.320 refid GPS
>
> server 127.127.28.1 minpoll 4 maxpoll 4 prefer
> fudge 127.127.28.1 refid GPS1
>
> [snipped out more comments]
>
> # you should not need to modify the following paths
> driftfile /var/lib/ntp/ntp.drift
>
> [snip]
>
> # To deny other machines from changing the
> # configuration but allow localhost:
> restrict default nomodify nopeer
> restrict 127.0.0.1
>
> ######################################################################
I could be wrong here, but it seems to me that your ntpd is having a hard
time finding out the actual time, as your only source of time is nearly 2
seconds off and varies wildly (GPS time does that, although not usually by
that much), and you have nothing else to go by. The PPS is probably not any
good unless it's within a second as ntpd would have no idea which second the
PPS is ticking, which might be why you mention the PPS's reach value will
increase when the GPS time offset gets under one second.
The GPS time is not very accurate anyway, and can vary wildly, probably
depending on the device, so don't expect perfect offsets. On my Garmin GPS
18 LVC, I use 0.190 which gets it in the ballpark, but can randomly jump
+16ms to -10ms at any time.
I would not use any time correction on your GPS time initially, to see how
far the device is off.
I also would connect the machine to the internet and add some pool servers
in your /etc/ntp.conf for a sanity check and to set the time initially.
Then start ntpd with the '-g' option, which allows for a one time initial
large adjustment, and should get it within a few ms of your configured
internet servers right away.
Ntpd should switch over to your PPS, SHM(1), shortly after you restart ntpd.
You can verify this with 'ntpq -p' and note where the asterisk '*' is. It
denotes the current system peer.
Once your ntpd settles down, note the offset of your GPS time in 'ntpq -p',
and fudge it by that amount. Note that the offset shown in 'ntpq -p' is in
milliseconds, and the time1 value is in seconds.
And you shouldn't use 'maxpoll 4' on refclocks, as any internet servers you
have configured will get clamped to the default minpoll of 6 (64 secs).
That creates unnecessary NTP traffic.
Here is the edited ntp.conf:
######## /etc/ntp.conf ################################
[snipped commented out stuff]
# Added 20080122 to sync to GPS
server 127.127.28.0 minpoll 4
fudge 127.127.28.0 time1 0.000 refid GPS
server 127.127.28.1 minpoll 4 prefer
fudge 127.127.28.1 refid PPS
# Sanity checks
server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
server 2.pool.ntp.org iburst
server 3.pool.ntp.org iburst
[snipped out more comments]
# you should not need to modify the following paths
driftfile /var/lib/ntp/ntp.drift
[snip]
# To deny other machines from changing the
# configuration but allow localhost:
restrict default nomodify nopeer
restrict 127.0.0.1
#######################################################
See how that works.
--
Dennis Hilberg, Jr. \ timekeeper(at)dennishilberg(dot)com
NTP Server Information: \ http://saturn.dennishilberg.com/ntp.php
_______________________________________________
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
