worley at theworld.com
worley at theworld.com
Fri Aug 22 19:48:35 UTC 2003
Like most other software, as NTP gains features, the documentation
becomes harder and harder for newbies to navigate. Currently, to get
NTP up and running, you really have to read a large fraction of the
documentation, and many people aren't going to have the stamina for
I am attempting to alleviate this by writing a "quickstart" document
that should suffice for almost all ordinary users. I've appended the
first draft and was wondering what people thought of it. Also, if
anyone has good pointers to solutions to common problems, and
especially considerations when using NTP over dial-up links, can they
forward them to me?
The main NTP documentation is http://www.eecis.udel.edu/~mills/ntp.
The NTP FAQ is http://www.ntp.org/ntpfaq/NTP-a-faq.htm.
An even quicker start is http://www.eecis.udel.edu/~mills/ntp/html/quick.html.
NTP Configuration Quickstart
These are "quickstart" instructions for configuring your NTP daemon.
They are a guide through the complexities of the NTP configuration
instructions. This guide should be enough to get you using NTP
successfully. Once your NTP daemon is working, you can adjust your
NTP configuration to take advantage of NTP's more sophisticated
I assume that you have already:
- installed NTP, either through your own efforts or because it comes
as part of your software distribution (You can obtain the source from
http://www.eecis.udel.edu/~mills/ntp/html/build.html. Building it
usually causes no problems.)
- discovered how to start, stop, and restart the NTP daemon (If NTP is
supplied as part of your system distribution, it will probably use the
same method as other system services. If you built and installed NTP
yourself, you will probably have to devise your own method.)
- discovered the location of the NTP daemon's configuration file
However, to make the NTP daemon useful, you have to customize the
configuration file. Though there are a lot of options, NTP
configuration is not all that complicated, because most people only
want to do a few simple things with it.
The NTP daemon functions as both a client and a server, communicating
using the NTP protocol (see RFC 1305). As a client, it receives time
information from one or more other servers. As a server, it can
deliver time information to one or more clients. Other
clients/servers that the NTP daemon communicates with fall into four
1. Servers the NTP daemon requests time from
2. Servers the NTP daemon accepts time from (if they offer it)
3. Clients the NTP daemon offers time to
4. Clients the NTP daemon gives time to (if they request it)
Each of these classes is configured individually. The clients/servers
that the NTP daemon actively contacts (classes 1 and 3) are specified
individually in the ntp.conf. Clients/servers join the other two
classes (2 and 4) by actively contacting the NTP daemon, if they are
permitted to join by the access control mechanisms.
Generally, a good policy is to (a) specify a small number of NTP
servers to be in class 1, so as to be the time sources for the NTP
daemon, (b) leave classes 2 and 3 empty, and (c) allow any NTP client
to join class 4.
First, you need to determine which NTP servers will supply your NTP
daemon with time. Ideally, you should choose three of these
"upstream" servers, so that you have triple redundancy in your timing
sources. Strategies to choose timing sources are (in decreasing order
- Talk to your organization's system or network administrators or your
- Find your organization's or ISP's NTP servers. Sometimes these have
obvious names like "ntp.example.com" or "ntp0.example.net". Sometimes
these can be discovered because many routers contain an NTP server,
and "ntpq -p <your-default-gateway>" or "ntptrace
<your-default-gateway>" will reveal them. Another method is to use
the service at http://www.abnormal.com/cgi-bin/findntp. You should
talk to the owner of the NTP server to ensure that you have permission
to use it.
- Use some of the public NTP servers listed at
http://www.eecis.udel.edu/~mills/ntp/servers.html. Remember to be
polite to public NTP servers, and follow their access policies, since
they are providing a public service.
Second, you need to determine which clients you are willing to supply
time to. Usually, you are willing to supply time to any client that
requests it, since a client imposes very little computational or
network burden on the NTP daemon.
Third, you also need to determine which IP addresses will be permitted
to examine the status of your NTP daemon, and which will be permitted
to remotely modify its configuration. We assume that you will allow
anybody to examine its status and nobody on another computer to alter
its configuration, as that is normally a safe policy.
Armed with this information, you can begin to construct your ntp.conf
file. In what follows, I will step you through everything needed to
make the file from scratch. But if you already have an ntp.conf file,
it is best to make the minimum edits from the distributed version, as
you will probably have to modify only a few lines, and the closer your
ntp.conf is to the distributed version, the easier it will be for you
to upgrade your NTP distribution with the next version, while
preserving your customizations. Editing ntp.conf files is not very
complicated, since the order of lines in ntp.conf does not matter.
Also, remember to save a copy of the original distributed file in a
place you won't forget (such as /etc/ntp.conf.orig).
# Comment lines in the NTP configuration file start with '#'.
# Blank lines are ignored.
# Set access control to prevent NTP from accepting time from servers
# that are not specifically authorized. Also, prevent remote
# reconfiguration of NTP.
restrict default nomodify nopeer notrap
# Solicit time from the servers that we have selected. Repeat the
# following block of lines for each server.
# Server ntp0.example.com
# The first line allows NTP to pay attention to time obtained from the
# server. The second line tells NTP to actively solicit time from the
# Unfortunately, the 'restrict' command must use the IP address of the
# server, not the DNS name.
restrict 172.16.14.200 nomodify notrap
# Server ntp1.example.com
restrict 192.168.1.19 nomodify notrap
# If you wish to offer time to an NTP daemon as well as request time from
# it, replace "server" with "peer" in its configuration line.
# If a server on your LAN is broadcasting/multicasting NTP
# information, use the appropriate following group of lines.
# To receive multicasting from server ntp2.example.com:
# This IP address is the NTP multicast group address, and should not change.
restrict 18.104.22.168 mask 255.255.255.255 nomodify notrap
# This IP address is the IP address of ntp2.example.com.
restrict 192.168.31.129 nomodify notrap
# To receive broadcasting from server ntp3.example.com:
restrict 10.142.160.12 nomodify notrap
# No additional configuration is needed to allow any client to
# request time from this NTP daemon.
# If this server should broadcast time on a LAN that this host is
# directly connected to, so that any NTP client on the LAN can
# passively receive time from it, add the following line. Replace
# "10.255.255.255" with the broadcast address for the LAN.
# If the NTP daemon cannot get time information from any of the
# servers, the following lines direct it to use the host's clock
# to keep track of time. Host clocks are reliable except that
# they run consistently fast or slow. When the NTP daemon can get
# time from another server, it measures the true frequency of the
# host's clock and saves that information in the "drift file".
# When it cannot get time from another server, it uses the saved
# information to correct the host's clock so that the clock is a
# reasonable time source.
fudge 127.127.1.0 stratum 10
# The name of the file in which the NTP daemon saves the
# correction for the host's clock. Use the file name that is
# supplied in your distribution, if it has one.
# Put this file in a directory which the NTP daemon can write to.
# This name must not be a symbolic link to the file, since the NTP
# daemon updates the file by creating a temporary in the same
# directory and then renaming it to this name.
Once you have your configuration file written, restart the NTP daemon
so that it re-reads the configuration file, and see how the NTP daemon
responds to the new configuration file.
The first thing to check is whether you made any syntax errors. The
NTP daemon logs any error messages into the system log while it is
processing the configuration file.
If the NTP daemon found no errors in your configuration file, start
watching its operation with the command:
~> /usr/sbin/ntpq -p
remote refid st t when poll reach delay offset jitter
LOCAL(0) LOCAL(0) 10 l 63 64 377 0.000 0.000 0.015
10.255.255.255 0.0.0.0 16 - - 64 0 0.000 0.000 4000.00
-chftp01.ne.ipsv tick.usno.navy. 2 u 225 1024 377 10.677 21.729 0.891
*BITSY.MIT.EDU GPS-1.MIT.EDU 2 u 365 1024 377 15.352 7.002 5.700
+ourconcord.net dtc-truetime.nt 2 u 342 1024 377 72.066 11.373 3.328
Each line of output describes one source that the NTP daemon is
accepting time from, or one client that it is actively offering time
to. The name of the time source or client is in the "remote"
column. In this example, "LOCAL" describes the host's clock (because
we included a "server 127.127.1.0" command), "10.255.255.255"
describes the broadcast of time to the LAN, and the remaining three
lines describe the servers specified in ntp.conf.
The first character on each line is the server's status. "-" and
"+" mark servers which the NTP daemon has decided are providing
reasonable time. "*" marks the server that the NTP daemon has
chosen as the best time source, and to which it is synchronizing the
"refid" is information received from the server, telling what source
the server is obtaining its time from.
"st" is the stratum at which the named server is operating. The
stratum of an NTP server is 1 higher than the stratum of the NTP
server it is obtaining its time from. If the server is obtaining
its time from a primary source, its stratum is 1, and if it is
obtaining time from its host's clock, its stratum is 1 more than the
"fudge stratum" number specified in ntp.conf (conventionally, 10).
The lower the stratum, the closer the listed NTP server is to a
primary time source. Generally, servers that are obtaining time
from reliable sources will have a stratum of 1, 2, 3, or 4. Stratum
10 means the host's clock, and NTP servers with stratums higher than
10 are getting their time from some host's clock. Stratum 16 means
that the server does not have a time source and is unsynchronized.
"poll" is the interval, in seconds, that the NTP daemon waits
between requests that it makes to the specified server. Upon
startup, poll will be 64 and will increase over time as the NTP
daemon gets better information about the server.
"when" is how long, in seconds, since the NTP daemon obtained time
from this server.
"reach" is an eight-bit octal number describing the results of the
last eight attempts to obtain time from this source. Upon each
attempt, a bit is shifted into this number from the right; one bits
indicate successes and zero bits indicate failures. So if we are
receiving time from the server, reach will start as "0", then 64
seconds (the poll interval) later, it will become "1", then 64
seconds later, it will become "3", etc. If contact is perfectly
reliable, reach will remain at "377".
"delay" is the round-trip delay when contacting this server, in
"offset" is the offset between this source's clock and the server's
clock, in milliseconds.
Another useful monitoring program is "ntptrace". It shows the chain
of NTP servers from which your host is obtaining time, asking each
server the name of the server from which it is obtaining time, ending
at the stratum 1 server that is obtaining time from a primary time
source. For example:
localhost.localdomain: stratum 3, offset 0.000038, synch distance 0.16418
ourconcord.net: stratum 2, offset 0.002985, synch distance 0.05762
dtc-truetime.ntp.aol.com: stratum 1, offset 0.000940, synch distance 0.00000, refid 'ACTS'
This listing shows the names of the NTP servers in the chain.
"stratum" is the stratum recorded by the NTP server.
"offset" is the offset (in seconds) that the NTP server computes
between its clock and the clock of its time source.
"synch distance" is the total round-trip time (in seconds) that the
NTP server computes between itself and the primary time source.
"refid" for the stratum 1 NTP server is the internal identifier of
the primary time source. This usually identifies the particular
type of primary time source.
When the NTP daemon first starts up, it will take it a few minutes to
contact each server and decide whether it is providing reliable time.
You can watch it do this, as the reach entries accumulate one bits and
as the status characters change. Within a few minutes, the NTP daemon
should choose one server to synchronize to, indicated by the status
character "*". Once the NTP daemon has done so, it will adjust the
host's clock to within 128 milliseconds of the server's time fairly
quickly, as you will see in the offset. Then over a period of a day
or two, it will decrease the offset to less than about 10
After a few days, the NTP daemon will have an accurate estimate of the
"drift", the error in your host's clock frequency. This is stored in
the drift file. Upon later restarts, using the drift estimate, the
NTP daemon will bring your host's clock into close synchronization
with the chosen source within about an hour.
If the host's clock is over 1000 seconds from the chosen server's
time, the NTP daemon will exit with a message to the system log. If
this happens: (1) Check that your computer is set to the correct time
zone. If the time zone is incorrect, the "local" time that most
commands report can appear to be correct, and yet the computer's
internal GMT time is incorrect. (2) Manually adjust the host's clock
to be within a few minutes of the true time, or execute "ntpq -q" to
cause the NTP daemon to force the host's clock to match that of one of
the servers. Then restart the NTP daemon.
If the host's clock is over 128 milliseconds from the chosen server's
time, the NTP daemon will adjust the clock in a single step. This can
cause the host's time to go backward. Because of this, do not run
applications that would be sensitive to "time running backwards" while
starting up the NTP daemon. (This is not usually a problem, as the
NTP daemon is normally started only when booting the system, and it
then runs continuously.)
Once the host's clock is within 128 milliseconds from the chosen
server's time, the NTP daemon will gradually adjust the clock to track
the chosen server's time. This adjustment is done by increasing or
decreasing the rate of the host's clock by up to 0.05%, one part in
2000. This should not disrupt any application.
For the first few days of operation, check "ntpq -p" periodically and
examine the system log for messages from the NTP daemon. If ntpq
shows that the NTP daemon is frequently unsynchronized, or if the
system log contains multiple "synchronization lost" or "time reset"
messages, it is possible that the NTP daemon is often choosing to
synchronize with a server that is not providing reliable time. Try
commenting out that server from ntp.conf and see if that eliminates
[Insert something here about dial-up connections.]
If you have problems that are not listed above, check to see if
something similar has been discussed in the newsgroup
More information about the questions