在混合環境中，機器可以在 Windows（大多數）、Linux（少數）、有時甚至是 Android 下運行……實現精度接近毫秒的時間同步的最佳解決方案是什麼？
我們正在開發基於微服務的解決方案，其中服務分散在我們設定中的多台機器上。在許多情況下，整合它們之間的資訊（日誌、監控等）需要一個共同的時間基準。
在 Windows 下使用 NTP 似乎有其限制。有任何可以在該作業系統上運行的開源解決方案嗎？我們無法保證我們的設定中始終存在 Linux 電腦。
答案1
[編輯] 當我剛剛憑記憶記下舊答案時，參考資料進行了重大重寫。
簡短的回答：不。如今，x86/x64 平台上的普通作業系統不可能獲得接近毫秒的精確度。
免責聲明 這是一個外行人的答案，因為我是一個普通的系統管理員，對電腦有普通的系統管理員視圖。一些核心開發人員和硬體架構師可能具有專業水平的計時知識。
長答案：
一個人必須從某個地方開始。我將從上至下進行此操作，從應用程式向下移動到振盪器開始。
第一個問題不是在一台電腦上進行計時，而是設法讓整個環境就您擁有的任何計時達成協議。什麼計時？事實證明，現在有幾種方法可以在計算機中記錄時間。我們最常看到的是系統時間（如螢幕一角所示）。讓我們先假裝事情就是這麼簡單，然後再把事情複雜化幾段。
我們希望系統時間是正確的，並且我們希望它在所有計算機上都是統一的。我們需要一種方法來從可信賴來源進行詳細的溝通，以滿足我們的需求。
讓我們把我們的要求變成1ms的容忍度，也就是說，我們的時間在我們的環境中可能會偏離1ms，或者我們錯過了一個關鍵目標。讓我們具體看看微軟能為我們做些什麼。
排除NT 等過時版本，Windows 本機基於簡化的ntp（以XP/2003 開頭的加入域的計算機）或簡化的sntp（以Win2k 開頭的未加入域的計算機）運行計時- 感謝@Ryan 對這個細節的挑剔。微軟設定了兩個目標在進行計時實現時，兩者都沒有達到我們期望的準確性水平：
「我們不保證也不支援網路上節點之間 W32Time 服務的準確性。W32Time 服務不是滿足時間敏感應用程式需求的全功能 NTP 解決方案。W32Time 服務主要旨在執行以下操作：下列的：
- 使 Kerberos 版本 5 驗證協定正常運作。
- 為客戶端電腦提供寬鬆的同步時間。
W32Time 服務無法可靠地將同步時間維持在一到兩秒的範圍內。這種容差超出了 W32Time 服務的設計規範。
好的。假設我們在不只一台電腦上執行您的服務堆疊，且事件關聯的計時容差水準接近 1 毫秒，這將是相當令人失望的。如果服務堆疊包含兩台計算機，我們實際上根本無法使用Windows本機計時。但是，當我們討論這個問題時，讓我們強調一下有關 Windows 本機計時的一兩個關鍵點，並包括一些完整的文檔：
如果您有 AD，請注意給定網域中的時間將從 PDC 模擬器角色（無論哪個 DC 具有該角色）進行同步。因此，需要透過運行 PDC 仿真器角色的網域控制器將正確的時間帶入網域。如果在多域林中，這將轉換為林根域的 PDC 模擬器。從那時起，時間主要分散到子域的 PDC 模擬器以及以扇出方式分散到每個域成員（有一些注意事項）。這個過程是記錄在這裡。更深入的訊息這裡
好的。我們可以做什麼？
首先，我們需要一或者其他更精確地同步整個環境的時間。假設我們無法運行 Linux ntpd 或Windows 版 ntpd你可以看看一個名為的共享軟體客戶端塔迪斯，但可能還有更多的嘗試。
我們在作為 PDC 模擬器運行的 Win2k3 伺服器上運行 Tardis，該伺服器的 CMOS 時鐘偏差非常大，由於無法解釋的歷史原因，我們別無選擇，只能從它同步整個網路。現在它已經被一個專用的 Linux ntpd 所取代，它從外部的原子鐘獲取時間，但 Tardis 當時就拯救了我們。但我不知道它是否可以幫助您實現比 Windows 本機更高的精確度。
但從現在開始，我們假設我們已經弄清楚如何實現完美的替代網路時間同步。由於其固有的狡猾性，它能夠容忍低於一毫秒的水平。我們已將其落實到位，以強制執行我們的 AD 期望的時間在網路中傳播的方式。
這是否意味著我們可以以接近單毫秒的粒度從作業系統和微服務中獲得準確的診斷？
讓我們看看 x86/x64 架構上的作業系統如何調度處理器時間。
他們使用中斷，即富含考古物質的多面獸。然而，作業系統並不是唯一想要中斷的系統。硬體也希望中斷，並且它有辦法做到這一點！ （你好鍵盤）作業系統也會配合。
這就是事情變得複雜的地方，我將透過過度簡化來解決這個問題。問題？我躲開，掩護並給你指出一個關於這個主題的絕對優秀的論文。 （如果您正在 Windows 平台上尋找毫秒，您確實應該閱讀它。）Win8.1/Win2012r2 的更新版本是據報道正在製作中但尚未公佈發布日期。
好吧，打斷一下。每當作業系統中發生某些事情時，中斷就會觸發隨後的操作。該操作是從核心獲取的一堆指令，可以在整批的不同的方式。最重要的是，儘管中斷發生的時間可以根據硬體架構和核心中斷處理以或多或少的精度確定，但後續執行部分發生的確切時間通常無法確定。一組特定的指令可能會在中斷後較早或較晚執行，它可能會以可預測的順序執行，也可能不會，它可能是有缺陷的硬體或編寫不良的驅動程式的受害者，影響甚至難以辨識的延遲。大多數時候人們根本不知道。隨後的日誌檔案中顯示的毫秒級時間戳記 -它非常精確，但是事件發生的時間準確嗎？
讓我們暫時停止計時中斷。中斷具有優先級，最低級別是用戶應用程式（例如標準服務）獲得處理器時間的位置。其他（更高）級別保留用於硬體和核心工作。如果高於最低優先權的中斷到達，系統將假裝佇列中不存在任何較低優先權中斷（直到處理了較高優先權中斷）。以這種方式運行的普通應用程式和服務將在處理器時間上排在最後。相比之下，時鐘中斷幾乎具有最高優先權。時間的更新幾乎總是在系統中完成。這對它的工作原理幾乎是一種犯罪的過度簡化，但它滿足了這個答案的目的。
更新時間其實包含兩個任務：
更新系統時間/又稱為掛鐘/又稱為當有人問我現在幾點時我所說的/又稱為 ntp 相對於附近系統來回擺弄的東西。
更新滴答計數，例如在測量程式碼執行持續時間時使用。
但無論是掛鐘時間還是滴答計數，系統從哪裡取得時間？這很大程度取決於硬體架構。在硬體中的某個位置，一個或多個振盪器正在滴答作響，並且該滴答聲是透過一的一些可能的路徑進入與核心聯繫的接口，因為它以或多或少的精度和準確度更新其掛起時間和滴答計數。
多核心系統中的振盪器佈局有多種設計模型，主要差異似乎是同步佈局與非同步佈局。描述了這些以及它們各自對精確計時的挑戰這裡例如。
簡而言之，同步計時每個多核心都有一個參考時鐘，它將其訊號分配給所有核心。非同步計時每個核心有一個振盪器。值得注意的是，最新的英特爾多核心處理器（Haswell）使用某種形式的同步設計，使用稱為「QuickPath Interconnect」和「Forwarded Clocking」的序列匯流排，參考文獻 1。數據表。轉發時鐘的描述使得外行人（我）可以快速掌握它這裡。
好吧，既然這些書呆子主義都已經拋開（這表明計時是一項複雜的實際任務，有很多關於它的歷史），讓我們更仔細地看看中斷處理。
作業系統使用兩種不同策略之一來處理中斷：滴答或無滴答。您的系統使用其中之一，但這些術語的含義是什麼？
滴答作響的內核以固定的時間間隔發送中斷。作業系統無法以比刻度間隔更精細的解析度來測量時間。即使如此，執行一個或多個操作所涉及的實際處理很可能包含大於滴答間隔的延遲。例如，考慮分散式系統（例如微服務），其中服務間呼叫固有的延遲可能會消耗相對大量的時間。然而，每組指令都將與作業系統以不比內核滴答時間更精細的分辨率測量的一個或多個中斷相關聯。滴答時間有一個基值，但至少在 Windows 中可以根據單一應用程式的需求減少。這是一個關聯的動作不僅有效益，也有成本，並攜帶相當多的精美印刷品用它。
所謂的無蜱粒（其名稱非常不具描述性）是一項相對較新的發明。無滴答內核以可變間隔設定滴答時間（未來的持續時間盡可能長）。原因是作業系統動態地允許處理器核心盡可能長時間地進入各種級別的睡眠狀態，其簡單目的是節省電力。 「各種等級」包括全速處理指令、以降低的速率處理（即較慢的處理器速度）或完全不處理。允許不同的核心以不同的速率運行，並且無滴答核心嘗試讓處理器盡可能不活動，即使在包括排隊指令以在中斷批次中觸發它們的情況下也是如此。簡而言之，多處理器系統中的不同核心允許在時間上相對於彼此漂移。這當然會對良好的計時造成嚴重破壞，到目前為止，對於較新的節能處理器架構和允許它們進行有效節能的無滴答核心來說，這是一個尚未解決的問題。將此與滴答內核（靜態滴答間隔）進行比較，滴答內核不斷喚醒所有處理器內核，無論它們是否接收實際工作，並且與無滴答內核相比，計時存在一定程度的不準確性，但相對可靠。
標準Windows 滴答時間（即係統解析度）為 15.6 毫秒直到 Windows 8/2012，預設行為是無滴答的（但可恢復為滴答核心）。我相信Linux預設tick時間取決於核心編譯，但是這個利基是遠遠超出了我的經驗（和這個太）所以你可能希望仔細檢查你是否依賴它。我相信 Linux 核心是從 2.6.21 開始編譯為無滴答的，並且可以使用各種標誌來優化無滴答行為（我只記得 no_hz 的幾個變體）。
裸機系統就這麼多。在虛擬系統中，情況會變得更糟，因為虛擬機器和虛擬機器管理程式以不同的方式進行爭用，這使得精確計時變得極為困難。這是VMware 概述和這是 RHEL KVM 的一個。對於分散式系統也是如此。雲端系統是甚至更困難因為我們還沒有接近看到實際的虛擬機器管理程式和硬體。
總而言之，從系統中獲得準確的時間是一個多層次的問題。現在從高層的角度來看，我們必須解決：硬體和核心之間的內部時間同步、中斷處理以及我們希望的指令執行延遲（如果在虛擬環境中不準確）由於封裝了第二個OS層，分佈式系統之間的時間同步。
因此，在計算歷史的這一點上，我們不會從 x86/x64 架構中獲得毫秒的精度，至少不會使用任何普通的作業系統。
但我們能有多接近呢？我不知道，不同系統之間應該會有很大差異。控制自己特定係統的不準確性是一項艱鉅的任務。一個只需要看看英特爾建議如何進行程式碼基準測試從這個角度來看，普通的系統，像是我剛好發現自己管理的系統，是非常失控的。
我什至不考慮實現“所有功耗優化、英特爾超線程技術、頻率縮放和睿頻模式功能均已關閉”在關鍵系統中，更不用說修補 C 程式碼包裝器並執行長期測試以獲得後續答案。我只是盡力讓他們活下去，並盡可能多地了解他們，而不過多打擾他們。謝謝你的時間戳，我知道我不能完全信任你，但我確實知道你沒有休息太多。當實際的毫秒精度確實變得很重要時，一次測量是不夠的，還需要更多的測量來驗證模式。我們還能做什麼？
最後，看一下很有趣即時作業系統人員如何看待中斷延遲。還有一個非常令人興奮的時間同步替代方案在作品中，有很多有趣的地方統計數據,方法和白皮書被公開。再加上未來的硬體架構和核心開發，幾年後計時精度問題可能不再是個問題。人們可能會希望。
答案2
time.windows.com 本身由 Microsoft 作業系統使用。如果您需要更具體的內容，我建議使用NIST 網路時間伺服器。如果您擔心篡改，他們甚至會運行經過身份驗證的 NTP。如果這還不夠，您可以隨時運行自己的。有許多供應商出售 1 層或 2 層 NTP 伺服器，您只需將其插入網路即可。層數是指用於驗證時間的不同方法。層 1 將只使用一種方法（NTP、CDMA、GPS），而層 2 將使用兩種方法。