NTP Server

proto.cs.earlham.edu is an ntp timeserver for Earlham's network. The time value it outputs come from some weighted average of two inputs. The first input is a NIST server located in Chicago. The second input is a GPS device on the fourth floor of dennis (in a box connected to the 4th floor lab's closet).

Explanation

Setup Procedure (Serverside)

Plug the GPS device into proto via USB. Make a symbolic link from the presence of the USB device on proto to /dev/gps0. Use the configuration file in the footer of this page or edit your configuration file to contain many of its ideas. Restart the ntp daemon.

Setup Procedure (Clientside)

Insert these lines into your ntp.conf: "server 159.28.230.6 prefer" and "fudge 159.28.230.6 stratum 1" The prefer parameter is optional, but its effect of weighting proto's signal more heavily in the ultimate time value is beneficial. The fudge line is also optional, but its effect of notifying ntp's algorithms of proto's stratum 1 quality is beneficial.

Managing the Client's NTP daemon

The "/etc/init.d/ntpd" command controls the ntp daemon. Passing it one of the parameters {restart, stop, start}, e.g. "/etc/init.d/ntpd restart" does exactly what you might imagine. After editing the configuration file to include proto as a server, you will need to restart the daemon for the changes to take effect.

Testing and Debugging

Type 'ntpdc' into your shell. That should give you an interpreter to which you will give the command 'peers'. If there is the value "=proto.cs.earlham.edu" in the first column of the output, then you are getting your time from proto.

Explanation of Choices

Since it is easy to configure one's time to a NIST timeserver and NIST uses highly accurate atomic clocks, you might wonder why we bother with the GPS. The locality of the GPS reduces network latency and network jitter as sources of error. While, for Earlham, the GPS signal may be more accurate, it is also less reliable. Somebody might accidentally unplug the GPS and HIP might not notice for a few hours/days, whereas the NIST server's importance means that attentive, skillful people would notice problems sooner. Considering this worst case scenario, and the fact that the different between 3:17:30 and 3:17:20 100% of the time is less important to most people than the difference between 4:17:30 and 3:17:30 0.28 percent of the time, it is best to mix the inputs

Troubleshooting

Currently the GPS is the gray cable running from Proto's front usb-port to the PVC pipe that runs outside.

The daemon is located at "/etc/init.d/ntp status".

NTP logs are located at "/var/log/daemon.log". In one circumstance the gps0 device was reporting that it wasn't found. It turned out that ttyUSB0 (the GPS) wasn't recognized despite it being plugged in. I unplugged and replugged the GPS. It worked.

To check if NTP is functioning correctly execute "ntpq -p" on clients or "ntpq -p proto.cs.earlham.edu" from within the CS subnet. The "when" field should be less than the "poll" field.

Clients

ACLs clusters?

The Server-Side Configuration File on Proto

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

#This is a backup from an intermediate stage of modification.
driftfile /var/lib/ntp/ntp.drift

# Enable this if you want statistics to be logged.
statsdir /var/log/ntpstats/

statistics loopstats peerstats clockstats 
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

server 216.171.120.36  maxpoll 4 minpoll 4 #chicago NIST
server 127.127.20.0 mode 0 prefer # the gps is a server
fudge 127.127.20.0 flag1 1 flag2 0 flag3 1 time2 0.600

# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details.  The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>
# might also be helpful.
#
# Note that "restrict" applies to both servers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.

#Allows all users on the Earlham network, characterized by IPv4 address
#starting with 159.28, to synchronize.
restrict default kod nomodify notrap
restrict 159.28.0.0 mask 255.255.0.0 nomodify notrap

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1