Monitoring NTP status
When the ntp
package is installed, you can monitor the
synchronization status of the machine's clock by running ntptime
.
For example, a system with a local clock that is synchronized may report:
ntp_gettime() returns code 0 (OK)
time de24c0cf.8d5da274 Tue, Feb 6 2018 16:03:27.552, (.552210980),
maximum error 224455 us, estimated error 383 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
modes 0x0 (),
offset 1279.543 us, frequency 2.500 ppm, interval 1 s,
maximum error 224455 us, estimated error 383 us,
status 0x2001 (PLL,NANO),
time constant 10, precision 0.001 us, tolerance 500 ppm,
Note the following most important parts of output:
-
maximum error 22455 us
: This value is well under the 10-second maximum error required by Kudu -
status 0x2001 (PLL,NANO)
: This indicates that the local clock is synchronized with the true time up to the maximum error above
In contrast, a system without NTP properly configured and running will output something like the following:
ntp_gettime() returns code 5 (ERROR)
time de24c240.0c006000 Tue, Feb 6 2018 16:09:36.046, (.046881),
maximum error 16000000 us, estimated error 16000000 us, TAI offset 0
ntp_adjtime() returns code 5 (ERROR)
modes 0x0 (),
offset 0.000 us, frequency 2.500 ppm, interval 1 s,
maximum error 16000000 us, estimated error 16000000 us,
status 0x40 (UNSYNC),
time constant 10, precision 1.000 us, tolerance 500 ppm,
The UNSYNC
status means that the local clock is not synchronized with the true time. Because of that,
the maximum reported error doesn't convey any meaningful estimation of the actual error.
ntpstat
utility reports a summary on the synchronization status of the
NTP daemon itself. For example, a system which has ntpd
running and
synchronized with one of its reference servers may report:
$ ntpstat
synchronised to NTP server (172.18.7.3) at stratum 4
time correct to within 160 ms
polling server every 1024 s
Keep in mind that the synchronization status of the NTP daemon itself doesn't reflect the synchronization status of the local clock. The way NTP daemon drives the local clock is subject to many constraints, and it may take the NTP daemon some time to synchronize the local clock after it itself has latched to one of the reference servers.
If more detailed information is
needed on the synchronization status of the NTP server (but not the synchronization status
of the local clock), the ntpq
or ntpdc
tools can be used
to get detailed information about what NTP server is currently acting as the source of the
true time and which are considered as candidates (either viable or not):
$ ntpq -nc lpeers
remote refid st t when poll reach delay offset jitter
------------------------------------------------------------------------------
-108.59.2.24 130.133.1.10 2 u 13 64 1 71.743 0.373 0.016
+192.96.202.120 129.6.15.28 2 u 12 64 1 72.583 -0.426 0.028
-69.10.161.7 204.26.59.157 3 u 11 64 1 15.741 2.641 0.021
-173.255.206.154 45.56.123.24 3 u 10 64 1 43.502 0.199 0.029
-69.195.159.158 128.138.140.44 2 u 9 64 1 53.885 -0.016 0.013
*216.218.254.202 .CDMA. 1 u 6 64 1 1.475 -0.400 0.012
+129.250.35.250 249.224.99.213 2 u 7 64 1 1.342 -0.640 0.018
$ ntpq -nc opeers
remote local st t when poll reach delay offset disp
------------------------------------------------------------------------------
-108.59.2.24 10.17.100.238 2 u 17 64 1 71.743 0.373 187.573
+192.96.202.120 10.17.100.238 2 u 16 64 1 72.583 -0.426 187.594
-69.10.161.7 10.17.100.238 3 u 15 64 1 15.741 2.641 187.569
-173.255.206.154 10.17.100.238 3 u 14 64 1 43.502 0.199 187.580
-69.195.159.158 10.17.100.238 2 u 13 64 1 53.885 -0.016 187.561
*216.218.254.202 10.17.100.238 1 u 10 64 1 1.475 -0.400 187.543
+129.250.35.250 10.17.100.238 2 u 11 64 1 1.342 -0.640 187.588