[ntp:questions] First attempt GPSD/PPS ->NTP time server

Dennis Hilberg, Jr. timekeeper at dennishilberg.com.invalid
Fri Jan 25 06:25:33 UTC 2008


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




More information about the questions mailing list