NTP Server

From Earlham CS Department
Revision as of 16:17, 23 January 2014 by Akseewa11 (talk | contribs)
Jump to navigation Jump to search

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

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

The Configuration File

# /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