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