This document serves two purposes. The first is to document the setup of an NTP client (not an NTP server.) The second is to allow other to see how to monitor NTP.
Enable syncing with upstream servers from your NTP source. These settings are set in /etc/ntp.conf
# Use public servers from the pool.ntp.org project. # Please consider joining the pool (http://www.pool.ntp.org/join.html). # Limiting to three servers as requested by pool.ntp.org server myTIME01.domain.com server myTIME02.domain.com
Now we need to make sure our time is somewhat accurate — within a minute or so. But before we do that we have to stop the ntpd daemon.
service ntpd stop
Now sync time
ntpdate -u qantp01.qa.testlab.com
Make sure the NTP daemon is enabled
chkconfig --list ntpd ntpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
If it’s not, enable it
chkconfig --level 2345 ntpd on
and verify
chkconfig --list ntpd ntpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
And restart the daemon
service ntpd start
Now we need to make sure time is syncing correctly. We can do this with ntpq \-p (or use \-np for ip’s, and not names.) This provided you with a list of time servers and the delay, offset and jitter that your server is experiencing with them. The delay and offset values should be non-zero and the jitter value should be under 100. The times are in milliseconds (1/1000 of a second.) The important thing to look for is the * you see in the first line. The * means you are syncing with a server on the internet. If you don’t see it right away, wait a few minutes and try again. It may take up to 15 minute for the local clock to get in sync with the remote server. Patience is your friend.
ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*qantp01.qa.test 209.20.66.253 3 u 113 256 377 0.165 -2.251 2.791
LOCAL(0) .LOCL. 10 l 27 64 377 0.000 0.000 0.001The first character in the leftmost column indicates the status of the peer, followed by the name or IP of the peer
“*” selected for synchronization
“o” selected for synchronization, PPS signal in use.
”+” included in the final selection set;
“sp” discarded as unreachable, synchronized to this server (synch loop) or outrageous synchronization distance;
“x” designated falsticker by the intersection algorithm;
”.” culled from the end of the candidate list;
”-” discarded by the clustering algorithm;
”#” selected for synchronization but distance exceeds maximum;The third column (st) is the stratum of your peer. LOCAL is a loopback address used for when no other clocks are available, and has a default setting of 10. Valid values are between 1 and 15. A value of 16 is a invalid stratum value representing “this server is not considered as a time provider”. This can be for various reasons, the most common reasons are “time provider not synchronized”, “configured source does not exist” or “ntp server not running”.
The fourth column indicates the type of server it is, and isn’t of much concern.
l = local (such as a GPS, WWVB)
u = unicast (most common)
m = multicast
b = broadcast
– = netaddr
The seventh column indicates reach, and should be at 377. An explanation of why from Linux Journal
Each remote server or peer is assigned its own buffer by ntpd. This buffer represents the status of the last eight NTP transactions between the NTP daemon and a given remote time server. Each bit is a boolean value, where a 1 indicates a successful transaction and a 0 indicates a failure. Each time a new packet is sent, the entire eight-bit register is shifted one bit left as the newest bit enters from the right.
The net result is that dropped packets can be tracked over eight poll intervals before falling off the end of the register to make room for new data. This recycling of space in the register is why it’s called a circular buffer, but it may make more sense to think of it in linear terms, as a steady, leftward march–eight small steps, and then the bit ends up wherever bits go when they die.
For reasons that seemed good to the developers, this register is displayed to the user in octal values instead of binary, decimal or even hex. The maximum value of an eight-bit binary number is 11111111, which is 377 in octal, 255 in decimal and 0xFF in hex.
The ninth column indicates offset in milliseconds, and should be less than 150
If you want to see how accurate your time is, you can use
ntpdc -c loopinfo offset: -0.064429 s frequency: -19.206 ppm poll adjust: 30 watchdog timer: 175 s
To see the remaining correction
[root@QANTP01 ~]# ntpdc -c kerninfo
pll offset: 4294.91 s
pll frequency: -19.206 ppm
maximum error: 0.437245 s
estimated error: 0.06018 s
status: 0001 pll
pll time constant: 6
precision: 1e-06 s
frequency tolerance: 512 ppmYou can get the same rough information from ntptime
ntptime ntp_gettime() returns code 0 (OK) time cd6e9ff0.43c3e000 Fri, Mar 20 2009 16:06:24.264, (.264708), maximum error 468477 us, estimated error 60180 us ntp_adjtime() returns code 0 (OK) modes 0x0 (), offset -60495.000 us, frequency -19.206 ppm, interval 1 s, maximum error 468477 us, estimated error 60180 us, status 0x1 (PLL), time constant 6, precision 1.000 us, tolerance 512 ppm,
To query your time server, but not change it, you can use ntpdate –q. However, you’ll need to supply an IP address. I suggest you use the one with the * when you do an ntpq –np, as that is the one you are using for syncing.
ntpdate -q 192.168.106.34 server 192.168.106.34, stratum 3, offset -0.001684, delay 0.02576 26 Mar 16:21:46 ntpdate[23454]: adjust time server 192.168.106.34 offset -0.001684 sec
You can also use ntpdate –d to look at the same information, but with debugging information.
ntpdate -q 192.168.106.34 server 192.168.106.34, stratum 3, offset -0.001684, delay 0.02576 26 Mar 16:21:46 ntpdate[23454]: adjust time server 192.168.106.34 offset -0.001684 sec ntpdate -d 192.168.10.10 26 Mar 16:22:28 ntpdate[23457]: ntpdate 4.2.2p1@1.1570-o Tue Jun 10 00:07:14 UTC 2008 (1) Looking for host 192.168.106.34 and service ntp host found : qantp01.qa.testlab.com transmit(192.168.106.34) receive(192.168.106.34) transmit(192.168.106.34) receive(192.168.106.34) transmit(192.168.106.34) receive(192.168.106.34) transmit(192.168.106.34) receive(192.168.106.34) transmit(192.168.106.34) server 192.168.106.34, port 123 stratum 3, precision -20, leap 00, trust 000 refid [192.168.106.34], delay 0.02576, dispersion 0.00000 transmitted 4, in filter 4 reference time: cd7688e3.2844bded Thu, Mar 26 2009 16:06:11.157 originate timestamp: cd768cb4.2295b2a8 Thu, Mar 26 2009 16:22:28.135 transmit timestamp: cd768cb4.22fc6972 Thu, Mar 26 2009 16:22:28.136 filter delay: 0.02579 0.02576 0.02579 0.02576 0.00000 0.00000 0.00000 0.00000 filter offset: -0.00164 -0.00164 -0.00165 -0.00164 0.000000 0.000000 0.000000 0.000000 delay 0.02576, dispersion 0.00000 offset -0.001646 26 Mar 16:22:28 ntpdate[23457]: adjust time server 192.168.106.34 offset -0.001646 sec
You can also use ntptrace to watch the system time synchronization (the –n flag turns off name lookups.) This will allow you to follow the time synchronization to it’s master time source.
ntptrace -n 192.168.106.34 192.168.106.34: stratum 3, offset -0.005207, synch distance 0.299721 209.20.66.253: stratum 2, offset 0.004282, synch distance 0.061297 192.5.41.40: stratum 1, offset -0.000018, synch distance 0.000000, refid 'USNO'
If you find you are experiencing trouble (and you’ve waited more than 15 minutes for your client clock to sync) you can enable more extensive logging. This is part of the /etc/ntp.conf configuration file.
# These should enable statistics to be kept statsdir /var/log/ntp/ statistics loopstats peerstats clockstats filegen loopstats file loopstats type day enable filegen peerstats file peerstats type day enable filegen clockstats file clockstats type day enable
Don’t forget to make the directory and make it readable by the ntp user (which the ntp daemon runs as.)
mkdir /var/log/ntp/
chown ntp:ntp /var/log/ntpNow restart ntpd
service ntpd restart
