 |
» |
|
|
|
The Network Time Protocol (NTP) is a family of programs used
to adjust the system clock on your computer and keep it synchronized
with external sources of time. All clocks drift including clocks
inside your computers. Computers are very sensitive to time deviations
caused by this drifting. NTP provides accuracy from the microsecond
to millisecond range. Some of the pervasive computing processes that may be affected
by disparity in time include, debugging, database and transaction processing,
and compiling software using the make utility. Debugging system problems becomes difficult if the timestamp
in the system logs are not true. Databases rely heavily on time. Databases and transaction
processing application may get confused if clients and servers have
differences in "correct" time. Many people use the make utility to manage the compilation of software. This
utility looks at file timestamps, with one-second granularity, to decide
which .0 files need to be rebuilt when the underlying source
file has been changed. The problem is compounded when files on machines
at various sites in different time zones need to be compiled and
built into the "new" version of the source files.
Also, if some of the directories are NFS mounted and the server
and client have different notions of the current time, then make can fail to rebuild some derived objects and produce
an executable that is not based on the most up-to-date sources. Even
the one-second granularity of file stamps means that your client and
server must be synchronized closer to 1000 milliseconds in order
to guarantee that make will compile the correct files. Equipment Needed for NTP | |
You will need the following equipment to effectively use the
NTP programs: Internet or your own radio receiver,
such as GPS, as a time source An ordinary network, like Ethernet, in your building A little knowledge about how to configure NTP and
get it working
Steps to Start NTP ConfigurationFor your basic NTP configuration, you will need to do the
following Choose a source of time. Determine how frequently your system clock should synchronize
with the source of time selected. Select back-up time servers. Configure your primary NTP server.
The following sections cover these steps in detail. Choosing the Source of Time | |
The time of day is officially defined, regulated, and distributed
by government organizations. These organizations coordinate with
one another and keep their clocks within nanoseconds of each other
at all times. The first step in using NTP is selecting the best
source of time for your organization. When selecting a source of time, you must be careful to choose
the source of time that will be best for you. Examine them carefully
and do not base your selection on price alone. If the kinds of applications
and processes your network users run are sensitive to time, it is
best to select the source of time that will provide stability and
will not be affected by network delays or outages. Also, select a source of time that you can reach. The closer
the source of time, the better. Choose a source that is physically
close and one that takes very few network hops to reach. For more
information on physical and network distance, seeXXXX "Configuring
Mulltiple Time Servers" on page 221. The most common time distribution mechanisms used from which
you can draw time are: public time server (phone or
modem) via the internet local clock impersonators radio receiver--terrestrial and satellite broadcast
Local Clock ImpersonatorsIf you are behind a firewall, not connected to the internet,
and cannot justify the expense of a radio receiver, you can still
have a time server. You can declare your NTP machine as a time server.
This machine can serve time within a closed domain. This is the
least recommended option. Because the server is isolated, it has
no way to synchronize to the real time. Beware, using this option
will cause problems if you ever connect outside of your domain. To set up the local clock impersonator, add the following
line to the /etc/ntp.conf file: server 127.127.1.1 minpoll 3 maxpoll 4 The radio receiver is the most accurate. When you use it,
you have no worries about network delays, congestion, or outages.
It is, however, the most expensive time distribution mechanism.
Some of the popular radio receiver method are: GPS (Global Positioning
System), WWV (terrestrial North America), and DCF77 (terrestrial
Europe). If you select the radio receiver, remember that you must consider
the cabling options. Antenna cables can be very expensive and RS232
cabling has a limited range. The official HP supported GPS receivers are HP58503 driver#26
and Trimble Palisade driver#29. The only supported WWVB receiver
is Spectracom Netclock/2 driver#4. DCF77 (AM and FM) signals radiate from
Frankfurt Germany. None of the DCF77 receivers are officially supported
by HP. To Set up a HP58503A GPS Receiver Install and connect the receiver and
antenna to a serial port on the HP-UX machine. Add the following files to the end of your /etc/ntp.conf file: server 127.127.26.1 minpoll 3 maxpoll 4
# fudge 127.127.26.1 time1 -0.955 #s700
# fudge 127.127.26.1 time1 -0.930 #s800 |
Uncomment the correct "# fudge" line
for your architecture. Uncomment the #fudge ... #s800 line for servers
or uncomment #fudge ... #s700 for workstations.
To Set up a Trimble Palisade GPS ReceiverInstall and connect the receiver and
antenna to a serial port on the HP-UX machine. Add the following files to the end of your /etc/ntp.conf file: server 127.127.29.1 #poll period is fixed at 32 seconds
# no fudge required
# fudge 127.127.26.1 time1 -0.930 #s800 |
Add the following to the device file (which device
file do you edit?) /usr/bin/ln -s /dev/tty0p0 /dev/palisade1 |
To Set up a Spectracom Netclock/2 Install and connect the WWVB receiver
to a serial port on the HP-UX machine. Add the following files to the end of your /etc/ntp.conf file: server 127.127.4.1 minpoll 3 maxpoll 4
# no fudge required
# fudge 127.127.26.1 time1 -0.930 #s800 |
Add the following to the device file (which device
file do you edit?) /usr/bin/ln -s /dev/tty0p0 /dev/wwvb1 |
Location of Time Source | |
When selecting a time server, it is best to select one that
is physically nearby. Selecting a time source that is too far away
can result in poor network connections and delays. Also consider
the network paths that packets will need to travel. If a time server
is physically nearby, but it takes an excessive number of network
hops to reach it, you will also experience network delays. If applications on your network need to be accurate down to
the millisecond, you must pay attention to the dispersion measurements
and the network service quality. Dispersion is
a measurement of the time server quality and network quality. | | | |  | NOTE: If the network is slow or overloaded, the dispersion
measurement will be high, regardless of the quality of the time
server or the network. | | | | |
The best time server for you is the time server that returns
a response from a PING the fastest. Figure 7-1 shows the best pimary
server is the server located in California, if you are in California.
The PING response time is only 5ms. The time server in New York
returns a response slower, but still is not bad. You would not want
to use the time server in Australia. The PING response time is 500ms.
This will cause lots of delays for your network users. Example 1: Locating the Best Primary Server In Table 7-1 “Available Time Servers”, you can see that there are
a number of servers the time client can access. The primary time
server is NAVOBS1.MIT.EDU. The other time servers within reasonable physical and
network distance are cs.columbia.edu, 129.236.2.199, and c.epsydra.dec.c . Table 7-1 Available Time Servers remote refid st t when poll reach delay offset disp
==============================================================================
clepsydra.dec.c usno.pa-x.dec 2 u 927 1024 355 108.49 -18.215 3.63
*NAVOBS1.MIT.EDU .USNO. 1 u 214 1024 377 38.48 -0.536 0.90
ticks.CS.UNLV.ED tock.CS.UNLV 3 u 721 1024 377 2113.97 1004.94 824.57
-cunixd-ether.cc 192.5.41.209 2 u 636 1024 377 47.99 3.090 9.75
+cs.columbia.edu haven.umd.edu 2 u 172 1024 377 3.39 12.573 1.14
+129.236.2.199 BITSY.MIT.E 2 u 423 1024 376 13.43 -14.707 22.60 |
|
Choose three (or more) that are nearby geographically. If
you are in London, it would not be wise to choose time servers in
Australia or Brazil. Long distances over water usually mean a poor
network connection in terms of delay and path symmetry. Router hops
also delay the packets in unpredictable ways. You will need to evaluate these potential time servers (and
the network paths) to decide if they are close enough (ping time,
delay and variation) and well configured before you use them. Some
time servers may also require notification before you use them,
so pay attention to the ettiquitte of the listings at UDelaware.
Do not point more than three of your machines at any one public
time server. Use that small group of your machines (at stratum-2
or stratum-3) as the main time servers for the rest of your organization.
For more information about stratum levels, see the section “Stratum Levels and Time Server Hierarchy”. The public stratum-2 servers can provide good timeservice
for almost anybody. Also, their access policies are less restrictive
than the stratum-1 servers. The quality of the network service
between your machine and the public time server (or your ISP) dominates
the errors you will see. This makes the distinction between stratum-1
and stratum-2 almost meaningless for most purposes. Dispersion is a measurement of time server quality plus network
quality. In reality, the network quality swamps everything else.
If your network is slow or overloaded, then dispersion will be high
no matter how good the time servers themselves are. NTP may be your
first experience with an application that is actually sensitive
to network service quality. Other applications (FTP, DNS, NFS,
sendmail) can tolerate huge delays in packet delivery because their
data is not time-critical. But NTP is different. Delays are deadly for your time service.
Delays immediately show up in the dispersion figures. If you care
about milliseconds, you must vigorously pursue your dispersion
measurements and pay attention to network service quality. If you
care about microseconds, you must abandon the network time servers
and purchase a radio clock for each NTP client. You can evaluate different public time servers from the stratum-2
list. First is a machine that HP is providing in Silicon Valley
for public use in North America. This machine was recently upgraded
from stratum-2 to stratum-1 with a new GPS receiver, but the lists
at UDelaware might not have been updated yet. ntp-cup.external.hp.com (192.6.38.127)
Location: Cupertino CA (SF Bay area) 37:20N/122:00W
Synchronization: NTPv3 primary (GPS), HP-UX
Service Area: West Coast USA
Access Policy: open access
Contact: timer@cup.hp.com
Note: no need to notify for access, go right ahead! |
If you are located in Silicon Valley, you can ping this time
server and see that it is about 5 milliseconds away: /usr/sbin/ping ntp-cup.external.hp.com 64 5 |
PING ntp-cup.external.hp.com: 64 byte packets
64 bytes from 192.6.38.127: icmp_seq=0. time=5. ms
64 bytes from 192.6.38.127: icmp_seq=1. time=4. ms
64 bytes from 192.6.38.127: icmp_seq=2. time=4. ms
64 bytes from 192.6.38.127: icmp_seq=3. time=5. ms
64 bytes from 192.6.38.127: icmp_seq=4. time=5. ms |
----ntp-cup.external.hp.com PING Statistics--- |
5 packets transmitted, 5 packets received, 0% packet loss
round-trip (ms) min/avg/max = 4/4/5 |
Determining Synchronization SourcesYou can query the time server using
ntpq -p to find out what synchronization sources it is using: /usr/bin/ntpq -p ntp-cup.external.hp.com |
Table 7-2 Locating Synchronized Time Servers remote refid st t when
poll reach delay offset disp=============================================================================
*REFCLK(29,1)
.GPS. 0 l 35 32 376 0.00 -0.004 0.02
-bigben.cac.wash
.USNO. 1 u 47 128 377 40.16 -1.244 1.37
clepsydra.dec.c
usno.pa 2 u 561 1024 377 16.74 -4.563 4.21
-clock.isc.org
.GOES. 1 u 418 1024 377 6.87 -3.766 3.57
hpsdlo.sdd.hp.c
wwvb.col. 2 u 34 16 204 48.17 -8.584 926.35
+tick.ucla.edu
.USNO. 1 u 111 128 377 20.03 -0.178 0.43
+usno.pa-x.dec.c
.USNO. 1 u 42 128 377 6.96 -0.408 0.38 |
This time server is synchronized (asterisk in column one)
to REFCLK(29,1), which is a Trimble Palisade GPS receiver. The
offset from GPS is currently 0.004 milliseconds and the dispersion
is 0.02 milliseconds (both excellent values, smaller is better here).
This time server also has several good stratum-1 and stratum-2
servers which it can fall back on if the GPS receiver stops working
for any reason. Notice the line for hpsdlo.sdd.hp.com which has delay, offset, and dispersion measures
that are markedly worse than any of the other sources. The time
server hpsdlo is good enough, but the network in between has
some problems, mainly evidenced by the large dispersion figure.
There is nothing that NTP can do to reduce the dispersion. NTP is
simply reporting to you what it sees out on the network. You must complain
to your network service provider if the dispersion numbers are too
high. In summary, ntp-cup.external.hp.com is a well-configured time server that is only
5 milliseconds away from my location (in California) on the network.
It would be a good choice for a public time server for my location.
Whether it is good for you depends on the "ping" round-trip times
at your location. Example 2: Evaluating Time Servers in Eastern United
StatesLook at the time server located on the east coast of North
America. Here are the details: ntp.ctr.columbia.edu (128.59.64.60)
Location: Columbia University Center for Telecommunications Research; NYC
Synchronization: NTP secondary (stratum 2), Sun/Unix
Service Area: Sprintlink/NYSERnet
Access Policy: open access, authenticated NTP (DES/MD5) available
Contact: Seth Robertson (timekeeper@ctr.columbia.edu)
Note: IP addresses are subject to change; please use DNS |
/usr/sbin/ping ntp.ctr.columbia.edu 64 5 |
PING 128.59.64.60: 64 byte packets
64 bytes from 128.59.64.60: icmp_seq=0. time=83. ms
64 bytes from 128.59.64.60: icmp_seq=1. time=86. ms
64 bytes from 128.59.64.60: icmp_seq=2. time=85. ms
64 bytes from 128.59.64.60: icmp_seq=3. time=86. ms
64 bytes from 128.59.64.60: icmp_seq=4. time=83. ms
----128.59.64.60 PING Statistics---- 5 packets transmitted, 5 packets received, 0% packet loss
round-trip (ms) min/avg/max = 83/84/86 |
These ping round-trip times are significantly greater than
the west coast example; the target is 5000 kilometers (3000 miles)
further away. Nonetheless, 85 milliseconds is not too bad for general
NTP purposes. You will generally see dispersion measurements somewhat
less than the ping round-trip times. The NTP daemon has an interesting
watershed at 128 milliseconds, but this example server at 85 milliseconds
is comfortably below that. You can use the server at columbia. /usr/sbin/ntpq -p ntp.ctr.columbia.edu |
Table 7-3 Evaluating Time Servers in Eastern United States remote refid st t when poll reach delay offset disp
==============================================================================
+clepsydra.dec.c usno.pa-x.dec.c 2 u 927 1024 355 108.49 -18.215 3.63
otc1.psu.edu .WWV. 1 - 17d 1024 0 28.26 -25.362 16000.0
*NAVOBS1.MIT.EDU .USNO. 1 u 214 1024 377 38.48 -0.536 0.90
tick.CS.UNLV.ED tock.CS.UNLV.ED 3 u 721 1024 377 2113.97 1004.94 824.57
132.202.190.65 0.0.0.0 16 - - 1024 0 0.00 0.000 16000.0
unix.tamu.edu orac.brc.tamus. 3 u 636 1024 377 47.99 3.090 9.75
at-gw2-bin.appl 0.0.0.0 16 - - 1024 0 0.00 0.000 16000.0
-cunixd-ether.cc 192.5.41.209 2 u 172 1024 377 3.39 12.573 1.14
cunixd.cc.colum 0.0.0.0 16 u 285 64 0 0.00 0.000 16000.0
+cs.columbia.edu haven.umd.edu 2 u 906 1024 376 2.41 -5.552 15.12
+129.236.2.199 BITSY.MIT.EDU 2 u 423 1024 376 13.43 -14.707 22.60
cucise.cis.colu cs.columbia.edu 3 u 62 1024 377 5.84 -1.975 12.70 |
|
This time server at Columbia University has a variety of stratum-1, stratum-2,
and stratum-3 sources, which is good. It also has three sources
which are not responding right now (reach=0), and one with very large
delay, offset, and dispersion (tick.CS.UNLV.EDU). As before, this
is due to networking problems between client and server (New York
to Las Vegas, over 3000 km), not some fault with the NTP implementation
at either end. This time server at Columbia is currently synchronized
to NAVOBS1.MIT.EDU, but three others (marked with "+" in column
one) are attractive and could step in immediately if NAVOBS1 failed
for any reason. Example 3: Evaluating Time Servers in AustraliaLook at a time server in Australia. Here are the details: ntp.adelaide.edu.au (129.127.40.3)
Location: University of Adelaide, South Australia
Synchronization: NTP V3 secondary (stratum 2), DECsystem 5000/25 Unix
Service Area: AARNet
Access Policy: open access
Contact: Danielle Hopkins (dani@itd.adelaide.edu.au) |
/usr/sbin/ping ntp.adelaide.edu.au 64 5 |
PING huon.itd.adelaide.edu.AU: 64 byte packets
64 bytes from 129.127.40.3: icmp_seq=0. time=498. ms
64 bytes from 129.127.40.3: icmp_seq=1. time=500. ms
64 bytes from 129.127.40.3: icmp_seq=2. time=497. ms
64 bytes from 129.127.40.3: icmp_seq=3. time=498. ms
64 bytes from 129.127.40.3: icmp_seq=4. time=496. ms |
----huon.itd.adelaide.edu.AU PING Statistics---- |
5 packets transmitted, 5 packets received, 0% packet loss round-trip (ms) min/avg/max = 496/497/500 |
Assume you are located in western United States and you ping
this time server. The ping round-trip times are much larger; around
500 milliseconds. Do not use a time server at this distance unless
you are really desperate and understand what 500 milliseconds step
changes mean to your users and applications. However, depending
on your location, ping round trip times from this server may be
acceptable levels. The round-trip times from your own location might
be much smaller. Also note that the variation in round-trip times
is small. /usr/sbin/ntpq -p ntp.adelaide.edu.au Table 7-4 Evaluating Time Sources in Australia |
remote refid st t when poll reach delay offset disp
=============================================================================
.otto.bf.rmit.ed 130.155.98.1 2 u 229 1024 376 16.34 7.132 7.87
.student.ntu.edu murgon.cs.mu.OZ 2 u 47 128 377 81.34 5.166 5.25
.203.31.96.1 murgon.cs.mu.OZ 2 u 13 256 373 115.74 30.147 38.54
.203.172.21.222 tick.usno.navy. 2 u 43 1024 367 866.64 47.316 65.32
-128.184.1.4 tictoc.tip.CSIR 2 u 99 128 377 13.40 -2.976 5.66
129.127.40.255 0.0.0.0 16 u - 64 0 0.00 0.000 16000.0
*tictoc.tip.CSIR .ATOM. 1 u 17 64 377 26.92 -0.071 1.71
.dishwasher1.mpc gilja.itd.adela 3 u 164 256 376 35.78 4.769 5.66
xclepsydra.dec.c usno.pa-x.dec.c 2 u 1468 1024 376 473.36 -53.841 12.89
murgon.cs.mu.OZ .GPS. 1 u 47d 1024 0 16.19 -398.80 16000.0
-augean.eleceng. murgon.cs.mu.OZ 2 u 12 128 377 1.83 3.270 1.21
.ns.saard.net augean.eleceng. 3 u 27 64 375 0.92 -0.013 1.19
+cuscus.cc.uq.ed tictoc.tip.CSIR 2 u 28 64 376 34.91 1.981 1.27
+staff.cs.usyd.e tictoc.tip.CSIR 2 u 3 64 375 25.21 0.158 1.97
.wasat.its.deaki tictoc.tip.CSIR 2 u 1 128 377 15.37 -2.492 1.69
.luna.its.deakin tictoc.tip.CSIR 2 u 123 128 172 16.11 -0.350 501.11
-earth.its.deaki tictoc.tip.CSIR 2 u 28 128 377 12.19 -3.582 2.15
phobos.its.deak tictoc.tip.CSIR 2 u 169 128 56 12.42 -2.325 1000.76
.sol.ccs.deakin. tictoc.tip.CSIR 2 u 136 512 265 13.89 -1.083 251.83
+argos.eleceng.a tictoc.tip.CSIR 2 u 23 64 377 1.82 0.197 1.21
.mercury.its.dea tictoc.tip.CSIR 2 u 123 256 377 16.91 -2.584 2.94
.orion.atnf.CSIR murgon.cs.mu.OZ 2 u 111 512 376 53.51 -0.712 5.92
+smig2a.City.Uni tictoc.tip.CSIR 2 u 49 64 376 7.14 0.268 1.07
+svdpw.City.UniS murgon.cs.mu.OZ 2 u 26 64 376 4.90 -0.833 1.88
.news.nsw.CSIRO. murgon.cs.mu.OZ 2 u 54 1024 377 135.85 43.108 62.45
+210.8.40.225 murgon.cs.mu.OZ 2 u 2 64 377 50.83 1.811 14.45
.203.103.99.66 tictoc.tip.CSIR 2 u 342 1024 376 82.82 -14.124 36.21
xpellew.ntu.edu. tictoc.tip.CSIR 2 u 408 1024 377 404.33 -159.77 161.36
xxox.lifelike.co tick.usno.navy. 2 u 494 1024 377 504.56 -59.200 5.60 |
|
|
This time server in Australia has one excellent stratum-1
source (tictoc.tip.CSIR) which it is currently synchronized to, one stratum-1 source
which hasn't responded in a while (reach=0), and a wide selection of stratum-2 sources (attractive
candidates marked with "+"). Some of the stratum-2 sources are
less attractive due to high delay, offset, and dispersion numbers.
They are marked "falseticker" ("x" in column one). This time server in Australia might be a good choice for you
if you are reasonably nearby, but it is probably not a good choice
for time clients in North America. When the time server in Silicon Valley is configured to use "sirius.ctr.columbia.edu" and "gpo.adelaide.edu" as time sources, the output from "ntpq -p" looks
like this (about 10 minutes after daemon startup): Table 7-5 Output from ntpq for Configuring Silicon Valley Time Server remote refid st t when poll reach delay offset disp
=========================================================================
*REFCLK(29,1) .GPS. 0 l 25 32 377 0.00 0.413 0.03
+bigben.cac.wash .USNO. 1 u 56 64 377 39.54 -0.466 1.68
clepsydra.dec.c usno.pa-x. 2 u 122 512 377 6.32 -0.250 0.92
-clock.isc.org .GOES. 1 u 149 512 357 5.98 -3.045 0.46
hpsdlo.sdd.hp.c wwvb.col.h 2 u 25 32 126 56.29 -8.078 8.50
+tick.ucla.edu .USNO. 1 u 13 64 177 19.29 -0.265 0.26
+usno.pa-x.dec.c .USNO. 1 u 56 64 277 6.82 0.034 0.20
gpo.adelaide.ed tictoc.tip 2 u 15 16 377 470.52 54.789 0.90
sirius.ctr.colu NAVOBS1.MI 2 u 3 16 377 83.37 -8.372 1.24 |
|
The time server in Australia has a delay of 470 milliseconds,
which is very similar to the "ping" round-trip times seen earlier.
This leads to an offset value of 54 milliseconds, which is significantly
worse than any of the other time sources. It is interesting to
note that the offest is much less than the delay, which means that
the round-trip is almost symmetric. NTP must assume the outbound
and inbound travel times are equal, and the offset value gives an
idea how unequal they might be. This is considerably better than
470/2 which would be the offset if NTP did not make this assumption.
Also interesting is the very low dispersion value, which means that
the round-trip time does not vary a lot as more packets are exchanged.
Less than 1 millisecond is an excellent dispersion value for a
trip of 15,000 kilometers. The time server in Australia is working
out better than we had any right to expect at this distance, but
it is still noticeably poorer than the other choices that are in
North America. The time server at Columbia is better than the time server
in Australia, due to the closer distance, but still noticeably worse
than all of the other time sources. You must choose a minimum of one time server, and it is a
good idea to choose three or more for redundancy. Then put lines
like this at the end of your /etc/ntp.conf file: server ntp-cup.external.hp.com
server bigben.cac.washington.edu
server sirius.ctr.columbia.edu Configuring Your Primary NTP Server | |
Install the latest version of NTP. Select a source of time: radio receivers, public time
server, local NTP machine. Add the name of the server to the file /etc/ntp.conf: server my_server.my_domain.my_org.com Note that my_server.my_domain.my_org.com is
the complete name of your server. Specify the time source and add its information to the
configuration file. For Radio Receivers: Uncomment the following "fudge" line
found at the end of the file /etc/ntp.confserver 127.127.26.1.
#fudge 127.127.26.1 time1 -0.955 Make a link to the device file that corresponds
to the serial port you are connecting to the GPS unit by typing
the following: /usr/bin/ln -s /dev/tty0p0 /dev/hpgps1
(device name for HP GPS) For the Local NTP Machine, add the following line
to the end of the /etc/ntp.conf file: server 127.127.1.1 fudge 127.127.1.1 stratum 10 Make a link to the device file that corresponds to the serial
port you are connecting to the GPS unit by typing the following: /usr/bin/ln -s /dev/tty0p0 /dev/hpgps1 Only use this option if NTP will be used in an isolated environment with
no radio clock, NIST modem or Internet connection available. You
can also use this if a particular server clock will be used as a
last resort, when all other normal synchronization sources have
gone away.
Start the NTP daemon. Edit the /etc/rc.config.d/netdaemons file. Set the variable NTPDATE_SERVER equal to an NTP
time server that is reachable. For example: NTPDATE_SERVER=15.13.108.1 This will run the /usr/sbin/ntpdate command just before the NTP daemon is started, and bring
your system clock very close to the other server to start. Set the XNTPD variable to 1. This will cause the daemon to be started automatically when
your system makes the transition from run level 1 to 2. Start the daemon using the startup script: /sbin/init.d/xntpd start Verify the daemon process is running. Type: ps -ef | grep ntp The line /usr/sbin/xntpd should appear in the list of running processes.
|
