The FAQ at support.ntp.org says to use at least 4 [1] because math.

But it basically boils down to "With at least four upstream servers, one (or more) can be a "falseticker", or just unreachable, and ntpd will have a sufficient number of sources to choose from."

I've spent a bunch of time sorting out NTP in recent years, chrony does indeed keep much better time and converge more quickly.

I would be careful about the advice around NTP anycasting. While attractive as a solution (one IP!), there are tradeoffs and it would be important to take those into account before going down this path.[2]

[1] https://support.ntp.org/bin/view/Support/SelectingOffsiteNTP....

[2] https://www.rfc-editor.org/rfc/rfc8633.html#page-17

Well, yes. Most computers have horrible clocks and can drift several seconds per day. That doesn't sound too bad, but eventually the error compounds and you are minutes then hours off from standard time, at which points lots of strange things can start happening, and the symptoms will vary based on whether your clock is drifting into the past vs the future. To fix it, you can always reset to the correct time.

Or just run an NTP client and never worry about it again.

If you have a cluster of servers doing some specific task (say, file server or database), having them all synced to the exact same time (down to a few miliseconds, at least) is usually critical to their operation. They use tokens, cookies, and whatever else to make a staggering number of decisions and compare timestamps against the system clock to prevent wasted resources managing state at every level.

If you're into systems administration or devops, eventually you will have a Very Bad Day when something important blows up and it's your job to find the root cause. Which usually means reading a lot of very big logs. If the machines that generated the logs are not perfectly synced (again, to the milisecond), then putting together a timeline of what happened when is basically impossible.

The negativity about using the NTP pool seems unwarranted. The NTP pool monitors all servers in it and will kick out those who are supplying incorrect times or who are unavailable.

You're also much more likely to be able to easily find a pretty good and pretty local set of NTP servers if you use the NTP pool, versus needing to look up other addresses for NTP servers. You don't need to use your country code in the FQDN for using the NTP pool, the DNS resolution should do a pretty good job of figuring it out for you and giving you rather local servers in response.

https://www.ntppool.org/en/use.html

The recommended way to use NTP is to run a daemon which will continue to run in the background ensuring your clock is accurate and to have it reference multiple time sources (or a known stratum 1 source, like an atomic clock, WWV station, GPS, etc).

If you're just syncing your clock once at boot, Google's time servers are probably fine to use, any time server is probably fine to use. Your hardware clock is going to drift over time but lots of times that's perfectly OK.

A pool server that's off by an hour would get kicked out of the pool within probably 20-40 minutes and not allowed back in until it was reporting the correct time for a reasonable duration. The current pool monitoring seems to go at a cadence of around 20 minutes to cycle through all the servers validating them. You can have a look at the log of the monitoring of one of my NTP pool servers: https://www.ntppool.org/scores/165.227.219.198/log?limit=200

> The recommended way to use NTP is to run a daemon which will continue to run in the background ensuring your clock is accurate

You'd might not want to have a daemon running in the background or install extra software in certain circumstances.

If you're using a lightweight solution such as systemd-timesyncd or ntpdate+cron it will only query one server, and you end up with the wrong time for ~30 minutes, which can cause major downtime or data corruption in certain circumstances.

Even if you're able to use a better client like chrony, it still doesn't solve the issues with leap seconds without extra configuration, which can cause the time to jump or move backwards, which can cause major downtime, e.g.

https://blog.cloudflare.com/how-and-why-the-leap-second-affe...

https://www.techspot.com/news/49229-leap-second-bug-amazon-e...

Yes, adding ntpd or chrony is another package but they really aren’t that big or burdensome on modern embedded systems. If you can fit systemd you can probably fit a real time daemon, too.

I could understand if you’re running in a system with single digit MB of ram or flash, maybe you can’t fit them, but those sizes systems today are quite rare.

For some pretty graphs, you can have a look at what the pool monitoring does for my pool servers: https://www.ntppool.org/a/bradfa

Not mentioned: but if you care about correct time be sure you are not using systemd-timesyncd or OpenNTPD. Both of those are better than nothing but chrony is much, much better. The "performance" section on this page has some numbers: https://chrony.tuxfamily.org/comparison.html

I have many OpenBSD systems and happily use openntpd, which is installed by default. It is perfect? No. Does it have a small attack surface? Yes. Does it keep my system’s time consistently correct and does it work well enough for this? Yes.

For using pool.ntp.org, this is a better resource:

https://www.ntppool.org/en/use.html

CentOS/RedHat uses the Chrony NTP agent, and has their own rhel domain within pool.ntp.org.

To only use NTP pool servers within your country, modify /etc/chrony.conf like so:

   server 0.us.pool.ntp.org iburst
   server 1.us.pool.ntp.org iburst
   server 2.us.pool.ntp.org iburst
   server 3.us.pool.ntp.org iburst

Hopefully, your country code is also defined as a subdomain.

You generally don't need to use the country code. The pool's DNS setup is usually smart enough to give you back servers who are fairly local to you based on your location, assuming your DNS server is fairly local to you.

If you're a vendor of a software or device who want to use the NTP Pool, you're asked to get a "vendor zone" which will have your name in the FQDNs used for accessing the pool. The cost to do this is fairly reasonable, much cheaper than running your own NTP infrastructure (I've done it for a former employer).

I've mostly moved to using time.cloudflare.com [1], in addition to the relevant ntp.org pools, because the ntp pool servers could often be wildly variable, while the cloudflare service appears to have been more stable.

[1] https://blog.cloudflare.com/secure-time/