DASH04: data_system Messages: 2 Entries..

Added "-P 20" option to /etc/sysconfig/ntpd, which I assume,
sets the real-time priority of the ntpd process.  

I can't find definite documention that it uses system routine
  sched_setscheduler(,priority,SCHED_FIFO)
but assume that it does.

On cosmos I set it to priority 45.  The thread that samples serial
ports runs at 50 and the thread that sends out samples to the
socket runs at 40, so ntpd will run in between.

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).