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

  • 6
    What alternate method would let you deal with keeping your clocks synched ? Even setting two clocks to the same time, accurate to the millisecond is impossible by hand and they'll soon diverge. Consumer-grade clocks are kinda rubbish.
    – Criggie
    Commented Nov 6, 2022 at 22:36
  • 24
    How do you know the internal clock is accurate?
    – OrangeDog
    Commented Nov 7, 2022 at 9:58
  • 2
    How do you tell your devices what time it is?
    – vidarlo
    Commented Nov 7, 2022 at 22:10
  • Is there something wrong with NTP in your environment ?
    – Criggie
    Commented Nov 8, 2022 at 1:34
  • 4
    Show me a device with an "accurate" internal clock and after a few months I'll show you how the clock in that device no longer displays the correct time. @vidarlo I've never seen a device that will display its system time where you cannot manually set the system time. So that's how you would tell the devices what time it is. It's about the same amount of work as telling all of your devices what their NTP servers are. Commented Nov 8, 2022 at 4:03

7 Answers 7


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.

  • 3
    Now if only the designers of those battery-less devices would set things up to be able to run ntpd -g (the just set the clock whatever the difference option) at boot...
    – Chris H
    Commented Nov 8, 2022 at 15:42
  • @ChrisH Now if only NTP didn't have a bunch of dependencies, like network...
    – Aron
    Commented Nov 9, 2022 at 6:31
  • @Aron, of course, but the use cases here tend to be inherently networked and the example that jumped to mind was a NAS drive that broke the timestamps on a backup after a power cut. Network can include cellular which gives you the time on connection (guessing here but NTP to the base station then part of the GSM or later protocol). Without network you could use GPS to set your RTC, but that depends on putting an antenna somewhere useful. In some places there's a good broadcast radio time service - my watch uses the UK one for example.
    – Chris H
    Commented Nov 9, 2022 at 6:57

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.

  • To add to your point about not all systems having an internal clock, I'm reminded of the important thing a clock that runs when the device isn't powered needs to keep time - it needs a battery. That can become an issue when the battery dies, as it famously did with Pokemon Gold and Silver. Commented Nov 8, 2022 at 9:52
  • Worse than about 1s setting by hand is either a poor UI or user error - take a typical Casio digital watch from any time in about the last 40 years, wait for your master clock to tick round to the top of the minute, and press the button to zero the seconds - you match to better than a human reaction time because of the rhythm
    – Chris H
    Commented Nov 8, 2022 at 15:44

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


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


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.

  • 4
    Even if you have an atomic clock (or, equivalently, a reliable GNSS signal, or some other PPS source), you still have to figure out what time it is supposed to be in the first place, because those can only indicate the passage of time, not the actual time. Commented Nov 7, 2022 at 2:22
  • 1
    @AustinHemmelgarn GNSS supplies a very accurate absolute time in UTC (derived from International Atomic Time (TAI)) so there’s no need to figure out what time it is. Just about every enterprise/telecoms grade NTP server on the market these days uses GNSS as a source of time, and the internal atomic oscillators (usually rubidium) are used to holdover the clocks should the GNSS signal be lost.
    – Darren
    Commented Nov 7, 2022 at 7:43
  • 1
    Please also note that at least the GPS time is not following UTC exactly, there is currently a difference of 18 seconds (it is tied to TAI -19 seconds). GST is TAI exactly, not sure about other systems.
    – PlasmaHH
    Commented Nov 7, 2022 at 15:31
  • 1
    @Darren I’m not claiming it would be, and my comments above were not intended to be about NTP servers, they were addressing the first part of the answer about not needing any external time reference if you have an atomic clock. Commented Nov 7, 2022 at 15:57
  • 1
    Even if you have an atomic clock and synchronized it, it will start to disagree with other atomic clocks due to differences in altitude and gravity. If you want to have standard time, you need to communicate with other timekeepers.
    – Nayuki
    Commented Nov 7, 2022 at 20:03

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.

  • Is the information of the video already summarised in your answer? It’s not really clear to me whether the video is supportive, auxiliary or additional information. (Disclaimer: I am not able to view the video.) Commented Nov 8, 2022 at 6:25
  • Yes, it covers one aspect - the performance of systems if they are kept in time sync. Here is part of the video description: By using an Atomic Clock the clocks between different computers can be synced to within a dozen nanoseconds, and with that performance can sky rocket. Check out the Open Compute Project: opencompute.org Build your own Time Card: github.com/opencomputeproject/Time-Appliance-Project And here is forum thread about this video: linustechtips.com/topic/…
    – KWriter
    Commented Nov 8, 2022 at 6:38

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...

  • Fair point. Actually experienced that myself when our mail log jumped back and forth during backup - the dumb ntp implementation on ESXi was broken and needed resetting. And obviously, we set up better monitoring of the hosts.
    – Zac67
    Commented Nov 9, 2022 at 18:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.