NTPD and Ntpdate under Linux

There is a more substantial difference between the two, ntpd in the actual synchronization time is a little bit of calibration over time, and finally the time to adjust slowly. And Ntpdate will not consider whether other programs will be painful, directly adjust the time. One is the calibration, one is the adjustment. In addition, NTPD in the synchronization process with the time server, the BIOS Timer oscillation frequency deviation-or the Local Clock Natural Drift (drift)-recorded. This way, even if there is a problem with the network, the machine can still maintain a fairly accurate walk.

There is also a detail to consider when using NTPD: If the client is unusually large or too small for the server, NTPD will reject the server reference time. There is also an unproven experience that, when the server is under a particularly stressful situation, ntpdate will make the right mistake, such as becoming a 1970-1-1. Reference

In General, try to use NTPD instead of ntpdate to synchronize time, Although Ntpdate is so criticized (even some children's shoes shout out do not recruit or cut off with ntpdate instead of ntpd lazy people:)), However, in some cases, ntpdate can still be considered:

? Cases where the time accuracy requirement is not high

? After the server restarts, NTPD is not started, use ntpdate to adjust the time, and then enable NTPD (note ntpd and ntpdate with a product 123, NPTD can no longer use ntpdate)

There are a few very obvious questions about how to adjust the time with ntpdate:

1. It is not safe to do so. Ntpdate's settings depend on the security of the NTP server, where an attacker can exploit some software design flaws, take down the NTP server, and perform some expendable tasks on the server that it synchronizes with. Since Ntpdate is in the same way as skipping, the server that follows it cannot know if an exception occurred (the only way to do this is by server).

2. This is not accurate. Once the NTP server goes down, the server that follows it will not be able to synchronize time. Unlike this, the NTPD is not only able to calibrate the computer's time, but also to calibrate the computer's clock.

3. This is not elegant enough. Because the ntpdate is a jump, instead of making time faster or slower, the timing-dependent program will go wrong. For example, if Ntpdate discovers that your time is fast, you may experience two of the same moments, which is fatal for some applications.

Many applications rely on continuous clocks, and the time to obtain them is linear. For example, database transactions often rely on the fact that time does not jump back. We can imagine the following, if the Oracle server time is 01:00 am, the standard time is 00:30 am, it is obvious that the Oracle server through his own time 00:40 am. If you are using Ntpdate to synchronize the server with standard time at this point, it means that the Oracle server will pass two 00:40 AM on the same day, which may be fatal for some scheduled tasks.
Thus, the only point that can make time jump is when the computer has just started, but not many services have started. The rest of the time, it is desirable to use NTPD to calibrate the clock instead of adjusting the time on the computer clock.