4 ms·
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 correct
by 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 agoWell, 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.