18.6 Setting Up the NTP Daemons
Now that I have my sources of time, I will set up a basic configuration. This will involve setting up the
/etc/ntp.conf
file and ensuring that my server is synchronized with those servers at boot time (
ntpdate
) and stays synchronized (
xntpd
). This is not difficult and should take only a few minutes. Here are the lines I added to
/etc/ntp.conf
:
server ntp0.cs.mu.OZ.AU
server ntp.metas.ch
server ntp-cup.external.hp.com
driftfile /etc/ntp.drift
The
server
directive should be quite easy to understand; it is followed by the hostname/IP address of the timeservers I am using. The order is not important because the
xntpd
daemon will work out which one it is going to use. The
driftfile
stores the current estimate of the frequency error of my own system clock. The
xntpd
daemon can use this value when restarted. Without it, the
xntpd
daemon can take up to a day to properly estimate this frequency error. Next, I can configure the startup file
/etc/rc.config.d/netdaemons
to synchronize my clock at boot time (
ntpdate
) and to keep me synchronized (
xntpd
). Here are the lines I amended in the file
/etc/rc.config.d/netdaemons
:
export NTPDATE_SERVER="ntp0.cs.mu.OZ.AU ntp.metas.ch ntp-cup.external.hp.com"
export XNTPD=1
export XNTPD_ARGS=
The
NTPDATE_SERVER
variable lists the servers I will attempt to contact in order to make a one-time step-change to my system clock. Again, the order is not important; the most suitable server will be
chosen
. And that's it for a
very
simple configuration. I just need to run the startup routine, and I will synchronize my clock now (
ntpdate
) and keep it synchronized (
xntpd
):
root@hpeos002[] #
/sbin/init.d/xntpd start
27 Aug 21:40:36 ntpdate[4956]: step time server 192.6.38.127 offset -0.005824 sec
xntpd root@hpeos002[] #
root@hpeos002[] #
First, we can see that the server ntp-cup.external.hp.com (192.6.38.127) was chosen for our initial synchronization (using the
ntpdate
command). We will check the status of our daemon with the
ntpq
(or
xntpdc
) command. It takes about 5 minutes for the daemon to
settle
down, so the first few times you run it, don't be worried if the
disp
value is quite high. Here's the output from
ntpq
just after I ran the startup routine:
root@hpeos002[] #
ntpq -p
remote refid st t when poll reach delay offset disp
=============================================================================
*murgon.cs.mu.OZ.GPS. 1 u 308 1024 377 337.54 -1.383 1.54
+metasweb01.admintp1.ptb.de 2 u 168 1024 377 97.31 18.001 18.31
+ntp-cup.externa.GPS. 1 u 411 1024 377 180.13 -2.831 4.30
root@hpeos002[] #
As you can see, our Swiss server is actually regarded as a Stratum-2 server with our selected server (the "*") going to our Australian cousins. Although the delay is high,
xntpd
has calculated the
disp
to be low. You should be worried if you cannot get a
disp
value of less than 100. Another important metric is the
offset
. The
offset
is the number of
milliseconds
that my system clock is offset from my timeservers. If the daemon cannot get this figure below 50, it shows that the daemon is working too hard to rectify my system clock with the timeservers. This is not a problem with NTP itself, but rather a problem with the reliability of our network connections.
I am now synchronized with my timeservers. I have just checked my system time with the time displayed at the Greenwich Meridian (http://www.greenwich2000.com), and I can find no disparity at all. That's good enough for me. We now configure other machines on my network to take advantage of our reliable time source. We first look at the relationships that different machines can have in the NTP network.
|