Can I synchronise local time with some NTP-server?

[Tom Limoncelli]

[ I'm CC:'ing webmaster at ntp.org so that he can add this as a "How to 
get started" document to the web site. ]

On Wednesday, June 4, 2003, at 03:37  PM, Constantine wrote:

> Hello!
>
> I am running FreeBSD 4.8. How can I synchronise my clock with some NTP 
> server? The time on my server right now is 4 minutes fast, and I do 
> not like that... Can I set up a script that would automatically 
> synchronise the time with some available server?
>
> My server is located in the USA, in case one would like to suggest 
> some good servers to synchronise with. :-)

I don't think that "read the man page" is a very good answer.  The man 
page doesn't explain things very well (if someone would like to submit 
what I write below to the maintainer, please do so).


Step 0:  Is it ntp or xntp?

Some operating systems supply binaries with the "x" and sometimes 
without the "x".  This document uses options that should work for 
either.  I'll always specify the command without the "x".  If you 
receive a "command not found", try it with an "x".


Step 1: Pick your servers

Find some public servers that you can sync with.  Two is good enough.  
There is a complete list here: http://www.ntp.org (it's a link to 
"http://www.eecis.udel.edu/~mills/ntp/servers.html")

These sites are kind enough to perform this service for you, you should 
follow any guidelines they request (asking permission first, donations, 
thank-you notes, whatever.)

Let's suppose you've picked clock.example.org and 
timekeeper.sample.com.  Those aren't real sites, but I'll use them as 
examples in the rest of this document.


Step 2:  "Manually" set the clock correctly just once

Let's "manually" set the clock to the correct time just to start things 
off.  When ntpd is running and finds your clock is wrong, it makes tiny 
little changes until the clock is right.  This way applications don't 
get confused.  However, on reboot, the clock may have lost a lot of 
time and since no applications are running yet, we can make a big 
timeleap to correct the clock.  To do this, we use a different utility 
called "ntpdate".  It can't run at the same time as ntpd.  We even give 
it the "-b" option so that it knows to leap forward or backwards in 
time to set the clock correctly.

Here's the command that does this:

             ntpdate -b clock.example.org timekeeper.sample.com
(NOTE: Substitute the 2 NTP servers that you'd like to sync with.)

Try this once from the command line (as "root") to make sure you're got 
it right.

# ntpdate -b clock.example.org timekeeper.sample.com
  5 Jun 08:50:18 ntpdate[23777]: step time server SOME_IP_ADDRESS offset 
-111.106949 sec

This means that your clock was off by -111.106949 seconds, but now it's 
been brought up to date.  The good news is that for an instant you were 
in sync.  The bad news is that by the time you read this, your clock 
has drifted. Darn computers!

Step 2:  Set the clock correctly on every boot up

On reboot, you want to tell the system to sync up quickly.  While your 
machine was down the CPU gets bored and plays with the clock.  Haven't 
you ever been in a clock store waiting for your mother to make her 
purchase and started setting the clocks to funny times?  It's like 
that, only your mother has nothing to do with this (I'm sure she's a 
very nice person, you just don't appreciate her enough).

Let's configure your system to run this command on boot up.  Here's how 
to do this on various operating systems:

FreeBSD:
Simply add this line to the end of /etc/rc.conf:
ntpdate_enable="YES"
ntpdate_flags="-b clock.example.org timekeeper.sample.com"

Solaris 9:
This is done automatically if a properly configured 
"/etc/inet/ntp.conf" exists.

(people can volunteer the easiest way to do this on their favorite OS)


Step 3: Keep the clock in sync permanently and continuously.

Having your clock set properly every time you boot is nice, if you 
reboot constantly.  Of course, you could put that command in "cron" but 
we have a solution that is so much better you'll thank me in the 
morning.  We'll run "ntpd" which will constantly keep your clock 
correct by making micro-adjustments all day long.  Heck, ntpd is so 
smart that if you lose contact with all your NTP servers it will 
remember how bad your clock was and keep making adjustments based on 
past bad performance.  Pretty cool, eh?

The NTP documentation has volumes about the various features and entire 
books can be written about the theory of operation of NTP.  It's really 
quite amazing how the system works so precisely, so accurately, does 
the right thing through outages, detects and avoids misconfigured 
servers, conserves bandwidth, and fixes problems that you don't yet 
realize you have.  However, you don't care about that, you just want a 
simple configuration that works.  Here's one:

Create a configuration file.  Different systems call it different 
things.
FreeBSD 4.x:  /etc/ntp.conf
Solaris 9: /etc/inet/ntp.conf

Put these 3 lines in your configuration file:

driftfile /etc/ntp.drift
server clock.example.org
server timekeeper.sample.com

Now start ntpd.

FreeBSD 4.x:
	/usr/sbin/ntpd -p /var/run/ntpd.pid
Solaris 9:
	/etc/rc2.d/S74xntpd start

It will now sync with the 'servers' in /etc/ntp.conf.  Once an hour it 
will record a little information in /etc/ntp.drift.  (/etc/ntp.drift 
contains what it needs to know if it loses contact with all your 
servers and needs to "go it alone").

Of course, you'll want to make sure that this command is run on bootup, 
after ntpdate is run (they can't run at the same time).  Here's how to 
do that on various operating systems:

FreeBSD 4.x:
Simply add this line to the end of /etc/rc.conf:
xntpd_enable="YES"
Then use "touch" to create some initial files:
	touch /etc/ntp.drift /var/log/ntpd.log
Solaris 9:
This is done automatically if a properly configured 
"/etc/inet/ntp.conf" exists.


Step 4: What about stratum 1, 2, 3 and all that?

You don't need to specify that in the configuration file.  If you list 
a mixture of stratum 1s, 2s, and 3s ntpd will do the right thing.  Your 
stratum is determined dynamically based on what you've synced to.  You 
don't need to worry about this.  However, if you want to know more, 
there is info in the documentation.


Step 5: Check your work.

"ntpdc" is a command that lets you talk to your ntpd (just like "lp" 
has "lpc").  It has a million features, but the one you really need to 
know is:

	ntpdc -c peers

 > ntpdc -c peers
      remote           local      st poll reach  delay   offset    disp
=======================================================================
=clock.example.o 5.0.0.0         16   64    0 0.00000  0.000000 0.00000
=timekeeper.samp 5.0.0.0         16   64    0 0.00000  0.000000 0.00000

Output like that (all zeros) means that we haven't synced with those 
two servers yet.

When things get synced, the numbers will fill out like this:

 > ntpdc -c peers
      remote           local     st poll reach  delay   offset    disp
=======================================================================
*clock.example.o 64.46.24.66    3   64  377 0.00018  0.000329 0.00255
=timekeeper.samp 61.26.45.88    3   64  377 0.00017  0.002122 0.00342

st -- the stratum of that server.
poll -- how often you poll that site (changes dynamically)

ntpdc can talk to remote machines if you have the proper access set up. 
    Just list the hostname on the command line:

% ntpdc -c peers ntp-2.cso.uiuc.edu
      remote           local      st poll reach  delay   offset    disp
=======================================================================
+ntp-1.gw.uiuc.e 0.0.0.0          2 1024  172 0.00627 -0.000044 0.00761
+tick.usno.navy. 0.0.0.0          1 1024  373 0.09023 -0.023207 0.15714
*truechimer.cso. 0.0.0.0          1 1024  377 0.00401 -0.000054 0.00006
+ntp-0.gw.uiuc.e 0.0.0.0          2  512  332 0.01059  0.001216 0.00497


Step 6: Running NTP on many machines in a network

If you have a lot of machines that need to be kept in sync, it is rude 
to point them all at public NTP servers.  It's also a waste of your 
internet bandwidth.  A much better solution is to set up 1-2 NTP 
servers on your network that point to public NTP servers, then point 
all your other machines at these 1-2 NTP servers.  This greatly reduces 
the amount of load you put on the public NTP servers.

At my company, we have 2 NTP servers: ntp1.mycompany.com and 
ntp2.mycompany.com.  Those are actually aliases ("CNAME" in DNS) that 
point to the 2 machine that I want everyone to use for NTP service.  We 
do another trick that makes the aliases point to different hosts 
outside our firewall.  That way the same configuration file works if a 
machine is connected inside or outside our firewall.

These 2 NTP servers need to have a custom configuration, that includes 
each other:
driftfile /etc/ntp.drift
# public NTP servers we sync to:  (use these 2 lines ONLY on ntp1 and 
ntp2!)
server clock.example.org
server timekeeper.sample.com
# Use these lines on all machines in mycompany.com:
server ntp1.mycompany.com
server ntp2.mycompany.com

I find that it is easier to have the exact same file on both of these 
servers.  That means that ntp1 will try to sync with itself, and ntp2 
will try to sync with itself.  Luckily, this is ok.  NTP will realize 
that its talking to itself and do the right thing (ignore itself).

All the other hosts have this ntp.conf:
driftfile /etc/ntp.drift
# Use these lines on all machines in mycompany.com:
server ntp1.mycompany.com
server ntp2.mycompany.com