Testing NTP Operation

Once you've configured your NTP server and restarted it, you should wait at least a few seconds, and ideally several minutes. You can then study the operation of the server by using the ntpq program. Type ntpq at a bash prompt and the program should respond with an ntpq> prompt. This program supports many commands; type ? to obtain a list of them. The most important command for testing basic operation is peers:

ntpq> peers remote refid st t when poll reach delay offset jitter

LOCAL(O) LOCAL(O) 10 1 34 64 377 0.000 0.000 0.031 *time.abigisp.ne tock.luna.edu 2 u 957 1024 377 60.899 5.873 9.742 +ntp.pangaea.edu ntp2.carbon.ati 2 u 54 1024 357 34.832 -6.425 1.658 +ntp.example.com 172.27.0.19 2 u 999 1024 377 43.758 1.519 0.831

This output reveals several pieces of information about the local server and the computers to which it synchronizes. This particular system ties itself to three peers—time.abigisp.net (the t at the end of the hostname is truncated), ntp.pangaea.edu, and ntp.example.com. The asterisk (*) next to time.abigisp.net's name indicates that it's the system to which the local server has tied itself, based on the quality of various measures, such as the delay, offset, and jitter values. The plus signs (+) next to the remaining two servers indicate that they're producing reasonable time values, but they aren't the servers that provide the signals that NTP considers best. Other information in this display includes the stratum of the source server (in the st column), when the server was last polled (under when), and the polling interval in seconds (poll).

If you use ntpq soon after starting your server, you won't see a main source server selected for a few minutes. This is because NTP must take several time readings to determine which source provides the best signal. Once it has done this, NTP's operation, and the output of the peers command inside ntpq, stabilizes. The polling interval is short (usually 64 seconds) in the beginning, but it grows to a value of several minutes (typically 1,024 seconds, or about 17 minutes).

If ntpq returns a connection refused message, this means that the NTP server isn't running on the system. The NTP server may abort if the system's clock differs from that of the servers to which it synchronizes by more than 1,000 seconds (just under 17 minutes). The reason for this is that such serious differences usually indicate a seriously incorrect clock or a server that's a false ticker. Either situation requires manual adjustment. In the case of a system clock that's set incorrectly, you can launch ntpd with the -g option, which overrides the 1,000-second rule. You can also set the clock in a one-time fashion manually (via the date command) or by using ntpdate. The ntpq program may also display a summary that indicates it's not obtaining reliable data from its upstream servers. If no server acquires an asterisk after a few minutes of running, that may be a sign of problems. Perhaps you've selected servers that aren't reliable or to which the network path is flaky, for instance.

0 0

Post a comment