我們中的許多人偶爾會遇到這樣的問題：我們的計算機和其他裝置保留了準確的時間設定，但是與NTP伺服器的快速同步會使一切恢復正常。但是，如果我們自己的裝置可能會失去準確性，NTP伺服器如何保持如此準確？

今天的問答環節是由SuperUser提供的，SuperUser是Stack Exchange的一個分支，是一個由社群驅動的問答網站分組。

圖片由LEOL30（Flickr）提供。

問題

超級使用者讀者Frank Thornton想知道NTP伺服器如何保持如此精確：

I have noticed that on my servers and other machines, the clocks always drift so that they have to sync up to remain accurate. How do the NTP server clocks keep from drifting and always remain so accurate?

NTP伺服器如何保持如此精確？

答案

超級使用者貢獻者Michael Kjorling為我們提供了答案：

NTP servers rely on highly accurate clocks for precision timekeeping. A common time source for central NTP servers are atomic clocks, or GPS receivers (remember that GPS satellites have atomic clocks onboard). These clocks are defined as accurate since they provide a highly exact time reference.

There is nothing magical about GPS or atomic clocks that make them tell you exactly what time it is. Because of how atomic clocks work, they are simply very good at, having once been told what time it is, keeping accurate time (since the second is defined in terms of atomic effects). In fact, it is worth noting that GPS time is distinct from the UTC that we are more used to seeing. These atomic clocks are in turn synchronized against International Atomic Time or TAI in order to not only accurately tell the passage of time, but also the time.

Once you have an exact time on one system connected to a network like the Internet, it is a matter of protocol engineering enabling transfer of precise times between hosts over an unreliable network. In this regard a Stratum 2 (or farther from the actual time source) NTP server is no different from your desktop system syncing against a set of NTP servers.

By the time you have a few accurate times (as obtained from NTP servers or elsewhere) and know the rate of advancement of your local clock (which is easy to determine), you can calculate your local clock’s drift rate relative to the “believed accurate” passage of time. Once locked in, this value can then be used to continuously adjust the local clock to make it report values very close to the accurate passage of time, even if the local real-time clock itself is highly inaccurate. As long as your local clock is not highly erratic, this should allow keeping accurate time for some time even if your upstream time source becomes unavailable for any reason.

Some NTP client implementati*** (probably most ntpd daemon or system service implementati***) do this, and others (like ntpd’s companion ntpdate which simply sets the clock once) do not. This is commonly referred to as a drift file because it persistently stores a measure of clock drift, but strictly speaking it does not have to be stored as a specific file on disk.

In NTP, Stratum 0 is by definition an accurate time source. Stratum 1 is a system that uses a Stratum 0 time source as its time source (and is thus slightly less accurate than the Stratum 0 time source). Stratum 2 again is slightly less accurate than Stratum 1 because it is syncing its time against the Stratum 1 source and so on. In practice, this loss of accuracy is so **all that it is completely negligible in all but the most extreme of cases.

有什麼要補充的解釋嗎？在評論中發出聲音。想從其他精通技術的Stack Exchange使用者那裡瞭解更多答案嗎？在這裡檢視完整的討論主題。