1. About NTP
NTP is used to synchronize the time of a computer client or server to another server or a referenced time source such as a radio, a satellite receiver or a modem. It provides client accuracy typically within a ms on a LAN or within 10ms over a WAN relative to a primary server synchronized to Coordinated Universal Time (UTC). Bringing up a NTP primary server requires a radio or satellite receiver or modem.
Time is distributed through a hierarchy of NTP servers, with each server adopting Primary (stratum 1) servers which are at the top of the pile and have access to some external time source, usually a radio clock. A stratum-2 server is one which is currently obtaining time from a stratum-1 server, a stratum-3 server would get its time from a stratum 2 server and so on. To avoid long lived synchronization loops the number of strata is limited to 15. If your network is isolated and you cannot access other people's servers across the Internet, a radio clock may make a good investment. Otherwise you would configure your server to one of the known primary or secondary NTP servers.
Each client in the synchronization subnet (which also may be a server itself) chooses exactly one of the available servers to synchronize to, usually from among the lowest stratum servers it has access to. Since this is not always an optimal configuration, NTP operates under another premise as well; i.e., each server's time should be viewed with a certain amount of distrust. NTP really prefers to have access to several sources of lower stratum time (at least three) since it can then apply an agreement algorithm to detect insanity on the part of any one of these. Normally, when all servers are in agreement, NTP will choose the best of these in terms of lowest stratum, closest (in terms of network delay) and claimed precisions, along with several other considerations.
Finally, there is the issue of association modes. There are a number of modes to choose from depending on the association between each of the servers. Configuring an association in symmetric-active mode (usually indicated by a peer declaration in the configuration file) indicates to the remote server that one wishes to obtain time from the remote server and that one is also willing to supply time to the remote server if need be. This mode is appropriate in configurations involving a number of redundant time servers interconnected via diverse network paths, which is presently the case for most stratum - 1 and stratum - 2 servers on the internet today. Configuring an association in client mode (usually indicated by a server declaration in the configuration file) indicates that one wishes to obtain time from the remote server, but that one is not willing to provide the time to the remote server. This mode is appropriate for file server and workstation clients that do not provide synchronization to other local clients. Where the requirements in accuracy and reliability are modest, clients can be configured to use broadcast or multicast modes. Where maximum accuracy and reliability are required, clients and servers operate in either client, server, or symmetric modes.
2. Setting up an NTP server
1. Copy over /etc/inet/ntp.server to /etc/inet/ntp.conf
# cp /etc/inet/ntp.server /etc/inet/ntp.conf
2. Edit ntp.conf file
I have added lots of comments in this file for clarification. Default file does not have many comments.
#----- start of ntp.conf file ---------------------
# @(#)ntp.server 1.4 97/05/05 SMI
#
# /etc/inet/ntp.server
#
# An example file that could be copied over to /etc/inet/ntp.conf and
# edited; it provides a configuration template for a server that
# listens to an external hardware clock, synchronizes the local clock,
# and announces itself on the NTP multicast net.
#
# SEE RFC 1305 ON FOLLOWING CLOCK DEVICES:
# This is the external clock device. The following devices are
# recognized by xntpd 3.4y:
#
# XType Device Name Description
# -------------------------------------------------------
# 1 (none) LOCAL Undisciplined Local Clock
# 2 trak GPS_TRAK TRAK 8820 GPS Receiver
# 3 pst WWV_PST PSTI/Traconex WWV/WWVH Receiver
# 4 wwvb WWVB_SPEC Spectracom WWVB Receiver
# 5 goes GPS_GOES_TRUE TrueTime GPS/GOES Receivers
# 6 irig IRIG_AUDIO IRIG Audio Decoder
# 7 chu CHU Scratchbuilt CHU Receiver
# 8 refclock- GENERIC Generic Reference Clock Driver
# 9 gps GPS_MX4200 Magnavox MX4200 GPS Receiver
# 10 gps GPS_AS2201 Austron 2201A GPS Receiver
# 11 omega OMEGA_TRUE TrueTime OM-DC OMEGA Receiver
# 12 tpro IRIG_TPRO KSI/Odetics TPRO/S IRIG Interface
# 13 leitch ATOM_LEITCH Leitch CSD 5300 Master Clock Controller
# 14 ees MSF_EES EES M201 MSF Receiver
# 15 gpstm GPS_TRUE TrueTime GPS/TM-TMD Receiver
# 17 datum GPS_DATUM Datum Precision Time System
# 18 acts NIST_ACTS NIST Automated Computer Time Service
# 19 heath WWV_HEATH Heath WWV/WWVH Receiver
# 20 nmea GPS_NMEA Generic NMEA GPS Receiver
# 22 pps ATOM_PPS PPS Clock Discipline
# 23 ptbacts PTB_ACTS PTB Automated Computer Time Service
#
# Some of the devices benefit from "fudge" factors. See the xntpd
# documentation.
# Either a peer or server. Replace "XType" with a value from the
# table above.
#If you are adding a local hardware clock device,
#its driver is identified here by a directive like: server
#127.127.XX.0 where 127.127 alerts NTP that this is a local rather
#than a remote network peer, and XX is a clocktype described in
#the NTP distribution. The restrict directive in this config file
#specifies that this host will only talk to the two IP addresses
#specified; it won't trust anyone else, and it won't serve time
#to anyone else.
#following three lines are there by default, change them according to your own setup.
server 127.127.XType.0 prefer
fudge 127.127.XType.0 stratum 0
broadcast 224.0.1.1 ttl 4
#three types of time servers
# 1. peer host_address [ key # ] [ version # ] [ prefer ]
# Specifies that local server is to operate in symmetric active mode with
# remote server specified as host_address, i.e.
# local server can be synchronized to the remote server
# 2. server host_address [ key # ] [ version # ] [ prefer ] [ mode] server
# Specifies that the local server is to operate in
# "client" mode with the remote server named in the com-
# mand. In this mode the local server can be synchronized
# to the remote server, but the remote server can never
# be synchronized to the local server.
# 3. broadcast host_address [ key # ] [ version # ] [ttl # ]
# Specifies that the local server is to operate in
# "broadcast" mode where the local server sends periodic
# broadcast messages to a client population at the
# broadcast/multicast address named in the command
#
# key Indicates that all packets sent to the
# address are to include authentication fields,
# encrypted using the specified key number. The
# range of this number is that of an unsigned
# 32 bit integer. By default, an encryption
# field is not included.
# version Specifies the version number to be used for
# outgoing NTP packets. Versions 1, 2, and 3
# are the choices; version 3 is the default.
# prefer Marks the host as a preferred host. This
# host will be preferred for synchronization
# over other comparable hosts.
# for complete listing see man page on xntpd
Sample ntp.conf file for an NTP primary stratum 1 server:
server 127.127.5.0
fudge 127.127.5.0 stratum 1
Sample ntp.conf file for an NTP server in peer mode:
peer ntppeerserver
Sample ntp.conf file for an NTP server in server mode: (Note: its recommended
to have a minimum of 3 server entries, even more preferable is 5)
server sometimeserver
server sometimeserver
server sometimeserver
server sometimeserver
server sometimeserver
We can always fall back to the local clock:
server 127.127.1.0
fudge 127.127.1.0 stratum 9
Once you have created your ntp.conf file, save it and start the xntpd daemon.
# /usr/lib/inet/xntpd &
you can specify different options for the daemon to run as:
-a Run in "authenticate" mode
-b Listen for broadcast NTP and sync to this if
available
-c -----> Specify an alternate configuration file
-d -----> Specify debugging mode. This flag may occur
multiple times, with each occurrence indicat-
ing greater detail of display
-e Specify the time (in seconds) it takes to
compute the NTP encryption field on this com-
puter
-f driftfile Specify the location of the drift file
-k Specify the location of the file which con-
tains the NTP authentication keys
-l logfile Specify a log file instead of logging to sys-
log
-m Listen for multicast messages and synchronize
to them if available (requires multicast ker-
nel)
-p ----> Specify the name of the file to record the
daemon's process id
-r Ordinarily, the daemon automatically compen-
sates for the network delay between the
broadcast/multicast server and the client; if
the calibration procedure fails, use the
specified default delay (in seconds)
-s Specify the directory to be used for creating
statistics files
-t trustedkey Add a key number to the trusted key list
-v Add a system variable
-V Add a system variable listed by default
3. Setting up an NTP client
1. Copy over /etc/inet/ntp.client to /etc/inet/ntp.conf :
# cp /etc/inet/ntp.client /etc/inet/ntp.conf
The default ntp.client file uses multicast to receive NTP updates. This can be changed to broadcast as well if you wish to limit where the NTP client can get its updates. (Broadcast packets are not forwarded to other subnets whereas multicast packets are).
#
# /etc/inet/ntp.client
#
# An example file that could be copied over to /etc/inet/ntp.conf; it
# provides a configuration for a host that passively waits for a server
# to provide NTP packets on the ntp multicast net.
#
multicastclient 224.0.1.1
2. Start the xntpd daemon
# /usr/lib/inet/xntpd -m &
(We start the xntpd daemon with the -m argument to listen for multicast packets if you were using broadcast as a method of receiving NTP updates you would use -b as the argument)
4. Using the ntpdate command.
The ntpdate utility sets the local date and time. To determine the correct time, it polls the Network Time Protocol (NTP) servers on the hosts given as arguments. This utility must be run as root on the local host. It obtains a number of samples from each of the servers and applies the standard NTP clock filter and selection algorithms to select the best of these.
It can be run on a regular basis from cron(1M) as an alternative to running a daemon. Doing so once every one to two hours will result in precise enough timekeeping to avoid stepping the clock. If you're are already running the xntpd daemon you can't use the ntpdate command. Trying to do so will generate the following error :
# ntpdate champ
23 Sep 14:55:52 ntpdate[19780]: the NTP socket is in use, exiting
You must also be root user to run the ntpdate command or you will see an error like this returned:
% ntpdate champ
23 Sep 14:44:36 ntpdate[19743]: bind() fails: Permission denied
In this example we specify the ntp server "jedi" to sync with.
# ntpdate jedi
23 Sep 17:12:21 ntpdate[20963]: adjust time server 129.148.192.147 offset 0.001422 sec
5. Using the ntpq command
ntpq queries NTP servers which implement the recommended NTP mode 6 control message format, about current state. It can also request changes in that state. The program can be run in interactive mode; or it can be controlled using command line arguments. Requests to read and write arbitrary variables can be assembled, with raw and pretty-printed output options available. By sending multiple queries to the server, ntpq can also obtain and print a list of peers in a common format.
To query an NTP server for a list of its peers:
# ntpq -p jedi
remote refid st t when poll reach delay offset disp
==============================================================================
*eastpager1.East dollar.East.Sun 3 u 97 64 376 2.03 4.564 2.33
LOCAL(0) LOCAL(0) 5 l 19 64 377 0.00 0.000 10.01
NTP.MCAST.NET 0.0.0.0 16 - - 64 0 0.00 0.000 16000.0
255.255.255.255 0.0.0.0 16 - - 64 0 0.00 0.000 16000.0
+sunswe.Sweden.S carbon.UK.Sun.C 3 u 48 64 377 156.80 6.367 0.41
+canadamail1.Can franc.East.Sun. 3 u 12 64 377 29.48 13.528 29.65
-cosmo.Eng.Sun.C rolex.East.Sun. 2 u 98 128 377 84.08 -1.069 0.87
-centralpager1.C venus.EBay.Sun. 3 u 41 128 377 68.73 -19.219 6.70
remote - is the remote peer
refid - is the host that the peer is synchronizing to
st - stratum number
t - type i.e. unicast, mulitcast, or local (a "-" equals don't know)
poll - polling interval in secs
reach - reachability register
* in remote indicates currently selected peer
+ means that the host is an acceptable peer for synchronization but not accepted
- not acceptable
6. Some useful debugging
When using "server" mode (association) it is advisable to have at least 3 different servers listed in the ntp.conf file. If the servers that you are configuring are out on the Internet and you have a firewall set up, you will want to make sure that there is a rule on the firewall that allows port 123 NTP traffic in and out from your NTP server. It will normally take about 5 minutes or more for your NTP server to become synchronized with the time servers listed in the ntp.conf. Until you become synchronized you will not start sending out broadcast/multicast NTP packets to other NTP clients. Normally these packets are sent every 64 seconds. Both xntpd and ntpdate have debug options but be aware that if you use ntpdate -d it will only "go through the motions" and not actually poll the network.
In this example we are using the ntp.client for ntp.conf and have turned on xntpd -d
# /usr/lib/inet/xntpd -d &
20743
# Solaris tick = 10000
kernel vars: tickadj = 625, tick = 10000
adj_precision = 1, tvu_maxslew = 61875, tsf_maxslew = 0.0fd70a37
create_sockets(123)
bind() fd 19, family 2, port 123, addr 00000000, flags=1
bind() fd 20, family 2, port 123, addr 7f000001, flags=0
bind() fd 21, family 2, port 123, addr 8194c097, flags=1
init_io: maxactivefd 21
report_event: system event 'event_restart' (0x01) status 'sync_alarm, sync_unspec,
1 event, event_unspec' (0xc010)
input_handler: fd=19 length 48 from 8194c093 129.148.192.147
input_handler: fd=19 length 48 from 8194c093 129.148.192.147
input_handler: fd=19 length 48 from 8194c093 129.148.192.147
input_handler: fd=19 length 48 from 8194c093 129.148.192.147
input_handler: fd=19 length 48 from 8194c093 129.148.192.147
input_handler: fd=19 length 48 from 8194c093 129.148.192.147
input_handler: fd=19 length 48 from 8194c093 129.148.192.147
(129.148.192.147 is the host "jedi")
And at the same time we started snooping the ntp client on port 123 (ntp) we are expecting to see either multicast or broadcast NTP packets.
# snoop -d le0 port 123
Using device /dev/le (promiscuous mode)
slave-192-1 -> NTP.MCAST.NET NTP broadcast (Thu Sep 23 16:42:15 1999)
champ -> NTP.MCAST.NET NTP broadcast (Thu Sep 23 16:42:46 1999)
jedi -> NTP.MCAST.NET NTP broadcast (Thu Sep 23 16:42:49 1999)
jedi -> BROADCAST NTP broadcast (Thu Sep 23 16:42:50 1999)
slave-192-1 -> NTP.MCAST.NET NTP broadcast (Thu Sep 23 16:43:19 1999)
champ -> NTP.MCAST.NET NTP broadcast (Thu Sep 23 16:43:50 1999)
jedi -> NTP.MCAST.NET NTP broadcast (Thu Sep 23 16:43:53 1999)
jedi -> BROADCAST NTP broadcast (Thu Sep 23 16:43:54 1999)
slave-192-1 -> NTP.MCAST.NET NTP broadcast (Thu Sep 23 16:44:23 1999)
7. Known Bugs
4060650 xntpd loops continuously burning cpu and leaking memory rendering
m/c unuseable
4097366 external clock hardware isn't supported by xntpd
4192098 xntpd does not synchronize with "c011 sync_alarm" on a few Ultra 5 systems
4130698 ntp installation / upgrade instructions for Solaris 2.6
4061948 SPARC only: 2.5.1 SUNWxntp Package Is Incompatible With Solaris 2.6
8. Additional resources for NTP
NTP project web site:
NTP RFC:
