What is the use of NTP server when devices have accurate time?

Question

Just as the questions says, why there would be an NTP server when the devices already got the internal clock and are accurate.

Answer 1

Internal clocks are only so accurate. With an uptime of months or sometimes years, your nodes can drift considerably from correct time. Also, some nodes lack a battery-powered RTC, so they default to some point in time on bootup and need to be set somehow. Incorrect time may cause confusion and even break some protocols.

NTP can provide accuracy within a few milliseconds, so if you e.g. analyze logs from various sources the time stamps will match very nicely.

Of course, you can use alternative protocols for synchronization, with more or less precision. Keeping the clocks manually on dozens or even hundreds of nodes does not look like a viable option.

Answer 2

Your question is based on a number of inaccurate assumptions.

First off, not all systems actually have an internal clock. The Raspberry Pi is a trivial example of such a system, but there are many others out there. These systems can generally maintain some semblence of accurate time while running, but they can’t maintain time while turned off. Such systems need some way to figure out the time when they start up, and it needs to be possible to do so automatically.

Secondly, many systems don’t actually keep exceptionally accurate time. RTCs typically found in modern systems are accurate to somewhere within the 1-5ppm range. Worst case, this is about 0.425s of drift in 24 hours. That’s actually not horrible, and quite often most systems can keep even more accurate time while running. But these numbers are not guarantees, are almost never constant, and need to be measured against some external standard to be properly quantified and compensated for. Furthermore, it’s not unusual for even more accurate time to be required for network protocols to work correctly.

Thirdly, even if you ignore the above two points, you have to get the clock set accurately in the first place for it to be accurate. Humans cannot do this very well by hand (most people can manage no better than about 5-10 seconds of accuracy when setting a clock by hand), so there needs to be some way to set the time properly in the first place. This becomes even more important when dealing with large numbers of systems because of the second point above. If you need accurate time across more than about a dozen systems, you generally need some way to set the time on all of them at the same time, or some way to have them synchronize automatically.

Answer 3

A slightly different perspective than the other answers, in the context of information security.

We do not really care about how time is precise. What we want to make sure of is that time is the same everywhere and that this commonality derives from a single source of truth.

NTP is great for that - you set the "true time"^* in one place, and then you have it maintained everywhere.

This is particularly important in time-sensitive services (where clocks must not differ by X seconds, but whether they are precise vs the world is not that important). The other typical case for homogenous time is system/services logs that must be correlated, and it is almost always done based on time.

Finally, you ultimately want to synchronize with a commonly agreed standard outside your company (typically ntp.org) because you can be asked to provide logs for a certain time period, and this is one of the most frustrating exercises.
If you have the capacity to answer with logs time-stamped against this standard reference you cut short a lot of discussions.

^{* this can be for instance the administrator's wristwatch time}

Answer 4

Leap seconds

Nobody likes them, but they are a part of UTC, so if you want your clock to be in UTC ( to be able to have the same timestamps as everybody else on the internet uses ) rather than TAI, you need a mechanism to keep track of them. NTP is one of the options.

Strictly speaking if you are moving fast or are at unusal distances from the earth gravity well your clock might also drift more than allowed from TAI/UTC

Answer 5

If your device has an internal atomic clock, naturally you don't need it

NTP servers derive their times from atomic clocks, which are accurate to 1 second in 300 million years.

Most devices take their timing from crystal resonators. A really good crystal might be accurate to a millionth of the stated frequency. There are 31536000 seconds in a year. That means your crystal gains or loses 31.5 seconds over a year on average. In normal commercial equipment like PCs, the crystal is unlikely to be that good (because you pay more for better components) and it's likely to be 10 times that error.

If your device has its own atomic clock then sure, you don't need regular updates from an NTP server. With a regular PC though, you're probably going to want more accuracy than that.

Or do it yourself

Of course there are alternatives. NTP didn't always exist. There's nothing stopping you resetting the PC's time at reasonable intervals, and that's what we always used to do, back in the day. If you've got internet access though, it's way more convenient to have the PC do it automatically.

Answer 6

NTP server can set the correct/exact time to more than one device. This is very important when you are working with systems that depend on the correct time.

If there is an internal clock it also needs to have starting value, someone has to enter the time at some point. How accurate can that entry be?

I saw a video Why is this PCIe Card RADIOACTIVE? some time ago and I think that it explains very well why exact time is important in specific scenarios.

Answer 7

In addition to the many cases already mentioned (clocks not really that accurate, startup time, etc.), I've seen many cases of VMs (virtual machines) which keep reasonably accurate time... until the VM is paused, for instance for maintenance, to move it to another host, or other similar operations.

Then when the VM resumes, it continues to keep track of time... As if that interruption wasn't there. A pause of 5 minutes? The VM is now 5 minutes late! I've seen VMs with an hour or two of lag following maintenances. You definitely want NTP to fix that ASAP...