We're running ntpd with a local reference clock on aster - an old
Lowrance GPS, connected to /dev/ttyS0.
First create the device link:
cd /dev
ln -s ttyS0 gps0
chmod 666 /dev/ttyS0
Here is the /etc/ntp.conf on aster:
############### /etc/npt.conf ##################################
# NMEA GPS
server 127.127.20.0 mode 1
disable auth
# Don't do step changes less than 10 seconds
tinker step 10
# classes:clock, peer, sys and sync, or all
# message types: info, events, statistics, status or all
# logconfig -syncstatus -sysevents
logconfig =syncall +clockall
#
driftfile /etc/ntp/drift
#
# mkdir /var/log/ntp
# chown ntp /var/log/ntp
statsdir /var/log/ntp/
#
statistics clockstats
filegen clockstats file clock type day enable
##################### end of /etc/ntp.conf #######################
I've also added a setserial low_latency to /etc/sysconfig/ntpd:
######## /etc/sysconfig/ntpd ############
OPTIONS="-U ntp"
setserial /dev/gps0 low_latency
######## end of /etc/sysconfig/ntpd #########
On cosmos /etc/ntp.conf looks like:
###### /etc/ntp.conf #############
server 192.168.0.1
driftfile /etc/ntp/drift
tinker step 10
###################################
On aster:
tcpdump -i any port 123
shows the updates between cosmos and aster about every 64 seconds
The plot of samples.sonic, from 13:00 to 17:00 MST on Jan 9 shows a
definite departure from 9000 samples (30hz sampling over 300 seconds)
for all the sonics. The # of samples varied in a continuous manner
in a range between 8980 and 9020, for all sonics together over that
time. This appears to be due to the ntp daemon slewing the clock.
The ntp daemon on aster (with the direct GPS clock) reported
lost synchronization until 15:38MST Jan 9. After that it seems
to be working well (and samples.sonic has settled down at 9000).