Difference between revisions of "NTP Server"
| Line 1: | Line 1: | ||
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). | 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)== | ==Setup Procedure (Serverside)== | ||
Plug the GPS device into proto via USB. | Plug the GPS device into proto via USB. | ||
| Line 13: | Line 13: | ||
The fudge line is also optional, but its effect of notifying ntp's algorithms of proto's stratum 1 quality 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. | 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. | 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 | 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 | ||
Revision as of 05:51, 26 June 2014
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).
Contents
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
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
