The maximum poll interval defaults to 10 s , but can be increased by the maxpoll option to an upper limit of 17 36 h. The minimum poll interval defaults to 6 64 s , but can be decreased by the minpoll option to a lower limit of 3 8 s. From man chrony. For example, minpoll 5 would mean that the polling interval should not drop below 32 seconds.
Note that intervals shorter than 6 64 seconds should generally not be used with public servers on the Internet, because it might be considered abuse. A sub-second interval will be enabled only when the server is reachable and the round-trip delay is shorter than 10 milliseconds, i. For example, maxpoll 9 indicates that the polling interval should stay at or below 9 seconds. Example: server myntpserver. Log in to comment. JS Community Member 26 points.
Over the Internet, accuracy to 10s of milliseconds is normal. This is because clock drift is now accounted and corrected for, which was not done in earlier, simpler, time protocol systems. A resolution of picoseconds is provided by using bit time stamps. The first bits of the time stamp is used for seconds, the last bits are used for fractions of seconds. As bits is used to count the seconds, this means the time will "roll over" in However NTP works on the difference between time stamps so this does not present the same level of problem as other implementations of time protocols have done.
If a hardware clock that is within 68 years of the correct time is available at boot time then NTP will correctly interpret the current date. The NTP4 specification provides for an "Era Number" and an "Era Offset" which can be used to make software more robust when dealing with time lengths of more than 68 years. Do not confuse this with the Unix Year problem. The NTP protocol provides additional information to improve accuracy. Four time stamps are used to allow the calculation of round-trip time and server response time.
In order for a system in its role as NTP client to synchronize with a reference time server, a packet is sent with an "originate time stamp". When the packet arrives, the time server adds a "receive time stamp". After processing the request for time and date information and just before returning the packet, it adds a "transmit time stamp".
When the returning packet arrives at the NTP client, a "receive time stamp" is generated. The client can now calculate the total round trip time and by subtracting the processing time derive the actual traveling time. By assuming the outgoing and return trips take equal time, the single-trip delay in receiving the NTP data is calculated.
The full NTP algorithm is much more complex than presented here. When a packet containing time information is received it is not immediately responded to, but is first subject to validation checks and then processed together with several other time samples to arrive at an estimate of the time.
The system clock is adjusted slowly, at most at a rate of 0. It will take at least seconds to adjust the clock by 1 second using this method.
This slow change is referred to as slewing and cannot go backwards. If the time offset of the clock is more than ms the default setting , ntpd can "step" the clock forwards or backwards. If the time offset at system start is greater than seconds then the user, or an installation script, should make a manual adjustment. See Chapter 3, Configuring the Date and Time. With the -g option to the ntpd command used by default , any offset at system start will be corrected, but during normal operation only offsets of up to seconds will be corrected.
Some software may fail or produce an error if the time is changed backwards. For systems that are sensitive to step changes in the time, the threshold can be changed to s instead of ms using the -x option unrelated to the -g option. Using the -x option to increase the stepping limit from 0.
It disables the kernel clock discipline and may have a negative impact on the clock accuracy. The drift file is used to store the frequency offset between the system clock running at its nominal frequency and the frequency required to remain in synchronization with UTC. If present, the value contained in the drift file is read at system start and used to correct the clock source.
Use of the drift file reduces the time required to achieve a stable and accurate time. The value is calculated, and the drift file replaced, once per hour by ntpd. The drift file is replaced, rather than just updated, and for this reason the drift file must be in a directory for which the ntpd has write permissions.
See Chapter 3, Configuring the Date and Time for information on how to use that tool. The operation of ntpd is explained in more detail in the man page ntpd 8. The resources section lists useful sources of information. See Section NTPv4 NTPv4 added support for the Autokey Security Architecture, which is based on public asymmetric cryptography while retaining support for symmetric key cryptography. Unfortunately, it was found later that the protocol has serious security issues, and thus Red Hat strongly recommends to use symmetric keys instead.
An attacker on the network can attempt to disrupt a service by sending NTP packets with incorrect time information. If only one time source is compromised or spoofed, ntpd will ignore that source. You should conduct a risk assessment and consider the impact of incorrect time on your applications and organization. If you have internal time sources you should consider steps to protect the network over which the NTP packets are distributed. If you conduct a risk assessment and conclude that the risk is acceptable, and the impact to your applications minimal, then you can choose not to use authentication.
The broadcast and multicast modes require authentication by default. If you have decided to trust the network then you can disable authentication by using disable auth directive in the ntp. Alternatively, authentication needs to be configured by using SHA1 or MD5 symmetric keys, or by public asymmetric key cryptography using the Autokey scheme. To implement symmetric key cryptography, see Section Virtual machines cannot access a real hardware clock and a virtual clock is not stable enough as the stability is dependent on the host systems work load.
For this reason, para-virtualized clocks should be provided by the virtualization application in use. When atomic clocks were first made, the potential for more accurate definitions of time became possible.
The atomic clocks are in fact far more stable than the rotation of the Earth and so the two times began to drift apart. For this reason UTC was introduced as a practical measure. It is kept within one second of UT1 but to avoid making many small trivial adjustments it was decided to introduce the concept of a leap second in order to reconcile the difference in a manageable way. Then only is it deemed necessary to introduce a one second adjustment, forward or backward.
However, these announcements are important only to administrators of Stratum 1 servers because NTP transmits information about pending leap seconds and applies them automatically. The daemon, ntpd , reads the configuration file at system start or when the service is restarted. The configuration commands are explained briefly later in this chapter, see Section A path to the drift file is specified, the default entry on Red Hat Enterprise Linux is:. If you change this be certain that the directory is writable by ntpd.
The file contains one value used to adjust the system clock frequency after every system or service start. See Understanding the Drift File for more information.
The noquery option prevents ntpq and ntpdc queries, but not time queries, from being answered. The ntpq and ntpdc queries can be used in amplification attacks, therefore do not remove the noquery option from the restrict default command on publicly accessible systems. See CVE for more details. Addresses within the range As the "restrict default" line above prevents access to everything not explicitly allowed, access to the standard loopback address for IPv4 and IPv6 is permitted by means of the following lines:.
Addresses can be added underneath if specifically required by another application. Hosts on the local network are not permitted because of the "restrict default" line above.
To change this, for example to allow hosts from the To allow unrestricted access from a specific host, for example A mask of By default, the ntp. The file will be read by the ntpd init script on service start. The default contents is as follows:. The -g option enables ntpd to ignore the offset limit of s and attempt to synchronize the time even if the offset is larger than s, but only on system start.
Without that option ntpd will exit if the time offset is greater than s. It will also exit after system start if the service is restarted and the offset is greater than s even with the -g option.
In order to use ntpd the default user space daemon, chronyd , must be stopped and disabled. Issue the following command as root :.
To prevent it restarting at system start, issue the following command as root :. To check if ntpd is installed, enter the following command as root :. NTP is implemented by means of the daemon or service ntpd , which is contained within the ntp package. To install ntpd , enter the following command as root :.
To enable ntpd at system start, enter the following command as root :. Open the network address given, or all the addresses associated with the given interface name. This option may appear multiple times. This option also implies not opening other addresses, except wildcard and localhost.
This option is deprecated. Please consider using the configuration file interface command, which is more versatile. Specify the name and path of the symmetric key file. This is the same operation as the keys configuration file directive. Specify the name and path of the log file. The default is the system log file. This is the same operation as the logfile configuration file directive. See ntp.
Do not listen to virtual interfaces, defined as those with names containing a colon. Do not fork. This option must not appear in combination with any of the following options: wait-sync. Specify the name and path of the file used to record ntpd 's process ID.
This is the same operation as the pidfile configuration file directive. This behavior mimics that of the old ntpdate program, which has been replaced with a shell script. The -g and -x options can be used with this option. Note: The kernel time discipline is disabled with this option. Specify the directory path for files created by the statistics facility.
This is the same operation as the statsdir configuration file directive. Specify a user, and optionally a group, to switch to. The user and group may be specified by name or numeric id. If no group is specified, then the default group for userid is used. Give the time in seconds between two scans for new or dropped interfaces. For systems with routing socket support, the scans will be performed shortly after the interface change has been detected by the system. Use 0 to disable scanning.
Seconds to wait for first clock sync. This option must not appear in combination with any of the following options: nofork, quit. If greater than zero alters ntpd 's behavior when forking to daemonize. Instead of exiting with status 0 immediately after the fork, the parent waits up to the specified number of seconds for the child to first synchronize the clock.
This provides the option for a script starting ntpd to easily wait for the first set of the clock before proceeding. Normally, the time is slewed if the offset is less than the step threshold, which is ms by default, and stepped if above the threshold. This option sets the threshold to s, which is well within the accuracy window to set the clock manually. Note: Since the slew rate of typical Unix kernels is limited to 0. Thus, an adjustment as much as s will take almost 14 days to complete.
This option can be used with the -g and -q options. Any arguments given after options are interpreted as server addresses or hostnames, with the iburst option implied. Associations with these are formed before any associations implied by the configuration file. The ntpd utility operates by exchanging messages with one or more configured servers over a range of designated poll intervals.
When started, whether for the first or subsequent times, the program requires several exchanges from the majority of these servers so the signal processing and mitigation algorithms can accumulate and groom the data and set the clock. In order to protect the network from bursts, the initial poll interval for each server is delayed an interval randomized over a few seconds. At the default initial poll interval of 64s, several minutes can elapse before the clock is set. This initial delay to set the clock can be safely and dramatically reduced using the iburst keyword with the server configuration command, as described in ntp.
Most operating systems and hardware of today incorporate a time-of-year TOY chip to maintain the time during periods when the power is off. When the machine is booted, the chip is used to initialize the operating system time. After the machine has synchronized to an NTP server, the operating system corrects the chip from time to time. In the default case, if ntpd detects that the time on the host is more than s from the server time, ntpd assumes something must be terribly wrong, and the only reliable action is for the operator to intervene and set the clock by hand.
This causes ntpd to exit with a panic message to the system log. The -g option overrides this check, and the clock will be set to the server time regardless of the chip time up to 68 years in the past or future — this is a limitation of the NTPv4 protocol.
However, and to protect against broken hardware, such as when the CMOS battery fails or the clock counter becomes defective, once the clock has been set an error greater than s will cause ntpd to exit anyway. Under ordinary conditions, ntpd adjusts the clock in small steps so that the timescale is effectively continuous and without discontinuities. Under conditions of extreme network congestion, the roundtrip delay jitter can exceed three seconds and the synchronization distance, which is equal to one-half the roundtrip delay plus error budget terms, can become very large.
The ntpd algorithms discard sample offsets exceeding ms, unless the interval during which no sample offset is less than ms exceeds s. The first sample after that, no matter what the offset, steps the clock to the indicated time. In practice, this reduces the false alarm rate where the clock is stepped in error to a vanishingly low incidence. As the result of this behavior, once the clock has been set it very rarely strays more than ms even under extreme cases of network path congestion and jitter.
Sometimes, in particular, when ntpd is first started without a valid drift file on a system with a large intrinsic drift the error might grow to exceed ms, which would cause the clock to be set backwards if the local clock time is more than ms in the future relative to the server. In some applications, this behavior may be unacceptable. There are several solutions, however.
0コメント