Shulou(Shulou.com)06/01 Report--

Today, I would like to share with you the relevant knowledge of how NTPD works. The content is detailed and the logic is clear. I believe most people still know too much about this knowledge, so share this article for your reference. I hope you can get something after reading this article. Let's take a look at it.

Network Time Protocol (NTP) is a protocol used to synchronize computer time. It enables computers to synchronize their servers or clock sources (such as quartz clock, GPS, etc.). It can provide high-precision time correction (the difference between LAN and standard is less than 1 millisecond, WAN is dozens of milliseconds).

How NTP works

The ntpd process obtains time information by periodically sending messages to the NTP clock source server. At the initial startup of the process, whether it is the first boot or subsequent startup, nptd sends a message to the server to get the time set to the local system. To prevent a network storm, a random delay value is added to the defined interval of 64 seconds after the process starts, which ranges from 0 to 16 seconds; therefore, it takes several minutes after the process starts to start the synchronization time.

Today's computers have a hardware clock chip (time-of-year (TOY) chip), which is used to keep the correct time when the computer is powered off. When the computer is powered on, the operating system acquires time from the clock chip. When the operating system starts up and connects to the clock source, the operating system will adjust the chip time according to the clock source. When the server does not have a hardware clock chip or the hardware clock chip fails (the CMOS battery is dead) or other reasons lead to a difference of more than 1000 seconds between the local time of the operating system and the clock source time, nptd believes that there is a serious problem at this time, and the only reliable way to deal with it is human intervention. In this case, the nptd Daemon process exits and records a log in the operating system's syslog. Nptd's startup option-g option can ignore the 1000 second check and force the clock source time to be set to hardware time, but considering the hardware clock chip failure scenario (CMOS battery is dead, or clock timer failure), nptd will exit once the chip time and clock source exceed 1000 seconds.

In general, ntpd adjusts the time in small steps so that the time is as continuous as possible without jumping. Under the condition of extreme network congestion, the delay of sending a message packet back and forth between the nptd and the clock source may reach 3 seconds, which will cause the synchronization distance (half round-trip delay, 1.5 seconds) to become very large. The ntpd synchronization algorithm will discard packets with a time difference greater than 128ms, unless there are no packets with a time difference less than 128ms in 900s, and will not check this time difference for direct synchronization at the first startup. This design is designed to reduce the alarm of false alarm of abnormal clock synchronization.

The result of the above behavior is that each time the local time is successfully set, it generally does not exceed the 128ms, even in the case of high network latency. Sometimes, especially when the ntpd starts for the first time, the jet lag may exceed the 128ms. In this rare scenario, the local time is more than 128 seconds faster (in the future) than the clock source, in which case the local time will be set back in the past. In this case, some applications will have problems. If the-x option is added when starting nptd, then nptd will not synchronize in stepped, only in slew correction.

The impact needs to be carefully considered before using the-x option. The maximum frequency of ntpd fine-tuning calibration is 500 PPM (parts-per-million) per second, that is, calibrating 5ppm 10000 seconds per second. As a result, it takes a long time to synchronize the time difference between the local time and the clock source to an acceptable range, about 2000 seconds, which is unacceptable for applications that rely on network clock sources.

Frequency rule

The behavior of nptd at startup depends on the existence of the frequency file, usually npt.drift. This file contains the recently estimated clock frequency error. If the file does not exist, ntpd enters a special mode and quickly adjusts the time and frequency error, which is good for about 15 minutes. Then nptd enters the normal mode after the time and frequency error is normal, and the time and frequency continue to synchronize with the clock source. And after an hour, the current frequency error is written to the npt.drift file. If the file exists, nptd reads the frequency error value from the file directly into the normal mode and does not write the calculated frequency error value to the file every other hour.

Operation mode

Nptd can run in a variety of modes, including symmetrical active and passive (active/passive), client, server (client/server), broadcast, multicast (broadcast/multicase/manycase), see Association Management for details. Usually, the operation mode is to continuously track the synchronization clock source time in Daemon mode; of course, it can be run only once to synchronize the time from the external clock source (reading the frequency error value from the last recorded frequency error file). In broadcast and multicast mode, the client can automatically discover the clock source server, calculate the delay of each server and then complete the configuration automatically. this mode makes the automatic configuration of workstation cluster become a reality.

By default, nptd keeps track of multiple clock sources in Daemon mode, and the interval of synchronization is determined by a complex state machine. The state machine uses a heuristic algorithm to calculate the optimal synchronization interval according to the message packet back and forth delay and frequency error. Typically, the state machine starts at an interval of 64 seconds and eventually reaches 1024 seconds, and a small number of random values are added to the interval to balance the server pressure. In addition, if a server is unreachable, the interval will gradually increase to 1024 seconds in order to reduce network message queue congestion.

In some cases, nptd can not run normally and continuously, and the usual circumvention is to use cron scheduled tasks to execute ntpdate commands. However, ntpdate does not consider a variety of signal processing, error checking and continuous synchronization algorithms like nptd. Nptd-Q can achieve the same effect as ntpdate, the-Q parameter causes npt to synchronize once and then exit; the process of synchronization is the same as nptd in Daemon mode.

If the operating system kernel supports clock frequency adjustment (Solaris,Linux,FreeBSD already does), then clock synchronization has an option that does not run in Daemon mode. First, nptd runs in Daemon mode, configures the clock source, obtains the frequency error npt.drift file after about an hour or several hours, then exits the nptd process and runs in one-time mode (nptd-Q), where each nptd run is synchronized with the clock source based on the current frequency error.

Synchronous interval control

The current version of NTP includes a complex state machine to reduce network load during synchronization, as well as a number of ways to improve precision. Users need to carefully consider the impact when modifying the synchronization interval (64-1024 seconds). The default minimum synchronization interval can be changed to no less than 16 seconds using the tinker minpool command, and this value will be used for all relevant uses to the synchronization interval, unless the display is overridden with the minpoll option. It should be noted that many device drivers do not work properly when the synchronization interval is less than 64 seconds, and broadcast and multicast modes are also the default values, unless overrides are displayed.

NPTD syntax ntpd [- aAbdgLmNPqx] [- c conffile] [- f driftfile] [- g] [- k keyfile] [- l logfile] [- N high] [- p pidfile] [- r broadcastdelay] [- s statsdir] [- t key] [- v variable] [- V variable] [- x] command line argument-a

"md_block md_has_block_below md_has_block_below_ul" > start authentication (enabled by default)-A disables authentication

-b

Use NTP broadcast message synchronization-c conffile to specify the profile name

-d

Enable debug mode-D level specifies the debug level

-f driftfile

Specify the path to the frequency error file-g normally, the threshold at which the time difference between ntpd and the clock source exceeds 1000 seconds will exit. If the threshold is set to 0, ntpd will not check and any jet lag will force synchronization. The-g option is used to set the threshold to 0; but it only takes effect once, and will exit if the jet lag is found to be more than 1000 seconds during the ntpd run.

-k keyfile

Specify the path to the NTP authentication key file-- l logfile specifies the log file path. The default is the operating system log.

-L

Listen synchronizes on virtual IP-m uses NTP Multicast messages at Multicast address 224.0.1.1 (kernel support required)

-n

No fork process-N priority specifies priority to run the ntpd process

-p

Specify the pid file for ntpd-- P overrides the priority limit of the operating system

-Q

Exit after synchronizing only once-r broadcastdelay specifies the default broadcast and multicast delay time

-s statsdir

Specify the directory where the files generated by the statistics tool are located-t key adds key to the trusted key list

-v.-V.

Increase the system variable;-x by default, ntpd uses fine-tuning mode when the time difference is less than 128ms and step mode when it is greater than 128ms. The-x option forces nptd to use only fine-tuning mode synchronization. If the step threshold (128ms) is set to 0, the step mode is forced, and-x does not take effect. This option is not recommended, which can cause time synchronization to become very slow and have an impact on applications that rely heavily on network clocks. The synchronization rate of the fine-tuning mode is 0.5ms/s, which takes 2000s to synchronize for 1 second.

These are all the contents of the article "how does NTPD work?" Thank you for reading! I believe you will gain a lot after reading this article. The editor will update different knowledge for you every day. If you want to learn more knowledge, please pay attention to the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.