3 ms·

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

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/SelectingOffsiteNTPServers#Section_5.3.3 https://support.ntp.org/bin/view/Support/SelectingOffsiteNTP.... [2] https://www.rfc-editor.org/rfc/rfc8633.html#page-17 https://www.rfc-editor.org/rfc/rfc8633.html#page-17

astrobe_ 5y ago
I've seen elsewhere deviations on the millisec scale and from my memories of reading the RFC NTP, the math is a lot about having a very precise time and correcting the local clock's deviation. Does it have an importance for everyday use, when you only see the seconds or your program's timers/dates are only caring about seconds, and the network is almost always available?
- bityard 5y ago
  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.

astrobe_ 5y ago

I've seen elsewhere deviations on the millisec scale and from my memories of reading the RFC NTP, the math is a lot about having a very precise time and correcting the local clock's deviation. Does it have an importance for everyday use, when you only see the seconds or your program's timers/dates are only caring about seconds, and the network is almost always available?

bityard 5y ago
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.