Windows的時間同步(w32time)與業務系統 ── 從機制原理解決「日誌時間戳記對不上」的問題

「裝置發生異常停止。把裝置端的日誌與PC端的應用程式日誌比對後,發現時間差了40秒,結果無法確定究竟是裝置的錯誤先發生,還是應用程式的通訊中斷先發生」── 這是我們在設備整合系統的故障調查中,一再遇到的場景。網路攝影機、PLC、檢驗裝置,以及Windows PC。每一個都用自己的時鐘刻劃日誌,而這些時鐘彼此是否對得上,其實從來沒有人保證過。

時間的落差在平常幾乎沒有人會注意到。真正麻煩的,永遠是在故障調查時,也就是需要把「事件的先後關係」當作證據使用的時候。而一旦開始調查,「工作群組的PC每週才同步一次」「虛擬機器同時從主機與NTP兩邊取得時間,結果左右搖擺」「裝置的時鐘打從一開始就沒有人校正過」這類事實就會接連浮現。

本文的對象是曾經為裝置與PC、伺服器與終端機的日誌比對所苦的開發者與資訊系統負責人,將以Microsoft的一手資料為佐證,整理Windows時間同步服務(w32time)的機制、以w32tm指令進行診斷的實務、精確度的現實期望值,以及在「時間會偏差、也會倒退」這個前提下,業務系統端應有的設計。

1. 先講結論

• Windows的時間由Windows Time服務(w32time)管理。它並非NTP的嚴格實作,而是一個使用NTP規格中的演算法群來調整時鐘的NTP用戶端/伺服器,通訊使用UDP 123連接埠。¹
• 網域環境有固定的時間階層。成員與DC同步,DC與父網域的DC同步,階層的頂點是樹系根網域的PDC模擬器。若頂點沒有與外部的精確時間來源同步,整個網域就會一起出錯。¹
• 工作群組(非網域)機器預設會與time.windows.com低頻率同步。登錄檔預設的SpecialPollInterval在獨立組態下為604,800秒(1週)。數十秒的偏差是「按規格運作」下自然會發生的結果。²³
• 診斷只需要一整套w32tm指令即可。w32tm /query /status 確認同步狀態與同步來源,/stripchart 實測與對方的時間差,/config /manualpeerlist 指定同步對象,/resync 立即重新同步。²
• w32time對小幅偏差會透過調快或調慢時鐘的前進速度來漸進校正(slew,滑動校正);對大幅偏差則會直接改寫時鐘來校正(step,階躍校正)。也就是說,系統時鐘有可能往前跳,也有可能往後跳。當偏差超過上限(MaxPos/MaxNegPhaseCorrection)時就不會被校正,只會記錄在事件記錄中,這一點同樣需要留意。¹²
• 預設設定的精確度,設計目標歷來只是「滿足Kerberos的5分鐘限制」這個程度。Windows Server 2016／Windows 10 1607以後大幅改善,只要滿足精確的Stratum 1時間來源、網路延遲、躍點數等條件,1秒/50毫秒/1毫秒的精確度就成為支援範圍。⁴
• Hyper-V來賓有主機與NTP兩個時間提供者。Windows Server 2016以後已改善為由來賓選擇最合適的一方,但在2012 R2以前的加入網域來賓上,建議停用Hyper-V時間同步提供者。³
• 應用程式端要以「時間會偏差、也會倒退」為前提來設計。日誌時間以UTC記錄,經過時間的測量則使用與系統時鐘無關、單調遞增的Stopwatch進行。這種區分是一切的基礎。⁵⁶

2. w32time的機制 ── 網域與工作群組的行為完全不同

Windows Time服務(W32Time)是Windows標準的時間同步元件。它透過NTP(以及供網域使用的安全MS-SNTP)從網路上的時間來源取得時間樣本,再以NTP的時鐘篩選/時鐘選擇演算法挑出最佳樣本,調整本機時鐘。¹

需要先掌握的是,依組態不同,同步對象的決定方式從根本上就不一樣。

在網域環境(Type=NT5DS)中,AD DS樹系內事先就定義好了時間階層。成員PC/伺服器與自己所屬網域的DC同步,DC再與父網域的DC同步,階層的頂點是樹系根網域的PDC模擬器(或組態設定為可信賴時間來源的DC)。NTP封包會以Kerberos工作階段金鑰簽署,只有經過驗證的時間才會被接受。¹ 因此,網域內的PC彼此之間通常會相當一致。問題出在頂點:若PDC模擬器沒有與外部的精確時間來源(GPS時鐘或可信賴的NTP伺服器)同步,就會變成「全員一起錯到同一個時間」。一旦把日誌拿去與公司外部的系統或雲端側的記錄比對,這個偏差就會立刻曝光。

flowchart TD
    EXT["外部的精確時刻來源<br/>GPS 時鐘 / 可信賴的 NTP 伺服器"]
    PDC["樹系根網域的<br/>PDC 模擬器"]
    CDC1["子網域的網域控制站"]
    CDC2["同一網域中的其他網域控制站"]
    M1["成員伺服器 / PC"]
    M2["成員伺服器 / PC"]
    M3["成員伺服器 / PC"]

    EXT -->|"這裡的設定由管理員負責"| PDC
    PDC --> CDC1
    PDC --> CDC2
    CDC1 --> M1
    CDC1 --> M2
    CDC2 --> M3

圖1:網域的時間階層 ── 箭頭表示時間分發的方向

把這棵樹畫成一張圖來看,就能清楚看出只要根出錯,所有人就會錯得一模一樣。而且因為大家是一起錯的,只要單看公司內部的日誌互相比對,就完全不會有人發現。要等到與外部比對的那一天,問題才會第一次被發現。這正是為什麼應該最先確認頂點設定的原因。

在工作群組環境(Type=NTP)中,預設的同步對象是 time.windows.com,0x1。0x1(SpecialInterval)是一個用SpecialPollInterval登錄值來決定輪詢間隔的旗標,它在獨立組態下的預設值是604,800秒=1週。² 即使是Windows 10用戶端,大約也只有一天一次,Windows Server 2012 R2世代的預設值則是每週一次。³ PC內建時鐘(石英振盪器)因溫度等環境因素,每天出現以秒為單位的漂移並不罕見,因此每週同步一次的話,數十秒的偏差是稀鬆平常會發生的事。開頭提到的「偏差40秒」,十之八九就是這個原因。

另一個在實務上很重要的,是時鐘規律(clock discipline)的運作方式。當偏差還小的時候,w32time會透過調快或調慢時鐘的前進速度來逐漸校正(slew,滑動校正);一旦偏差超過MaxAllowedPhaseOffset,就會直接設定時鐘(step,階躍校正)。¹² 此外,若偏差超過MaxPosPhaseCorrection/MaxNegPhaseCorrection(獨立組態預設為54,000秒=15小時),就會不進行校正,只記錄事件。² 若遇到「應該有在同步,卻怎麼都調不回來」的情況,有可能就是碰到了這個上限。而且,階躍校正也會往負方向作用,也就是說Windows的系統時鐘是有可能往後跳的── 這正好銜接到後半段應用程式設計的話題。

3. w32tm指令實務 ── 確認現狀、實測差值、變更同步對象

在時間相關的調查中實際會用到的指令,大概只有5個。以下全部都要在具有系統管理員權限的命令提示字元中執行。²

首先是確認現狀。

w32tm /query /status

うるう秒インジケーター: 0(警告なし)
階層: 4 (二次参照 - (S)NTP で同期)
精度: -23 (ティックごとに 119.209ns)
ルート遅延: 0.0312500s
ルート分散: 7.7756348s
参照 ID: 0xC0A80A14 (ソース IP:  192.168.10.20)
最終正常同期時刻: 2026/07/22 8:14:02
ソース: dc01.example.local
ポーリング間隔: 10 (1024s)

需要看的重點有3個:「ソース」(來源)是否是預期的對象(若顯示為 Local CMOS Clock 或 Free-running System Clock,代表實質上處於未同步狀態)、「最終正常同期時刻」(最後成功同步時間)是否是最近的時間(若是好幾天前,代表同步並未發揮作用)、「階層」(Stratum)是否合理(距離精確的時間來源有幾段,w32time只接受Stratum 15以下)。⁷ 若只想知道同步來源,用 w32tm /query /source;查看多個同步對象的狀態用 w32tm /query /peers;查看設定值及其出處(來自原則還是本機)用 w32tm /query /configuration。

以上輸出來自日文地區設定的Windows。在英文環境下項目名稱會不同,以下列出對應關係,供與海外據點人員溝通,或用英文搜尋資料時參考。另外要注意,由於顯示名稱會隨地區設定而改變,請不要撰寫按這份輸出機械式剖析的指令碼。

接著是實測與對方之間的時間差。在故障調查中,這用於把「伺服器與這台PC現在相差多少」量化成具體數值。

w32tm /stripchart /computer:192.168.10.20 /samples:5 /dataonly

192.168.10.20 [192.168.10.20:123] の追跡中。
現在の時刻は 2026/07/24 9:41:03 です。
09:41:03, +28.1246875s
09:41:05, +28.1250120s
09:41:07, +28.1248533s
09:41:09, +28.1251008s
09:41:11, +28.1249517s

從這個範例可以立刻判斷出「這台PC比對方慢了約28秒」。由於 /stripchart 只是用於顯示的測量,不會變更本機時鐘,因此可以放心地在運作中的裝置PC上執行。在開始比對日誌之前,對所有相關機器都執行一遍,先做出偏移量一覽表,再著手比對── 這是本公司在故障調查中最先要做的事。

要明確指定同步對象,需使用 /config。指定內部NTP伺服器(或DC)的標準做法如下。

w32tm /config /manualpeerlist:"ntp1.example.local,0x8 ntp2.example.local,0x8" /syncfromflags:manual /update
w32tm /resync

0x8 是以用戶端模式同步的旗標,與 0x1(SpecialInterval)組合(即 ,0x9)後,會依SpecialPollInterval所指定的間隔進行輪詢。若只指定 0x1,用戶端模式的旗標會被拿掉,因此若要指定間隔,應寫成 ,0x8 或 ,0x9。若只能準備2台伺服器,建議為其中一台加上 0x2(UseAsFallbackOnly)以明確優先順序(Microsoft的建議是,若能準備3台以上會更好)。² 若要停止手動指定、恢復為網域階層同步,執行 w32tm /config /syncfromflags:domhier /update 並重新啟動服務。w32tm /resync 會捨棄累積的誤差統計並立即重新同步,可用於確認設定變更後的生效情況。²

伺服器名稱後面附加的數值就是NtpServer旗標。這些內容分散各處容易被誤用,以下整理成一張表。²

請不要單獨指定 0x1。由於用戶端模式的旗標不會被設起,這會變成只指定了間隔卻不進行同步的組態。想指定間隔的話,應使用 0x9。

縮短工作群組PC的輪詢間隔

第7章判斷表中提到的「縮短SpecialPollInterval」,是透過變更登錄值並重新啟動服務來完成的。把預設的604,800秒(1週)改為3,600秒(1小時)的步驟如下。²

rem (1) 將輪詢間隔設為3,600秒(REG_DWORD的數值以十進位指定)
reg add "HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient" /v SpecialPollInterval /t REG_DWORD /d 3600 /f

rem (2) SpecialPollInterval只對帶有 0x1 旗標的時間來源有效,以 0x9 指定
w32tm /config /manualpeerlist:"ntp1.example.local,0x9 ntp2.example.local,0x9" /syncfromflags:manual /update

rem (3) 重新啟動服務使其生效,並立即同步
net stop w32time && net start w32time
w32tm /resync

rem (4) 確認生效結果,以及各設定值的出處(來自原則還是本機)
w32tm /query /configuration
w32tm /query /status

若省略(2),即使只變更登錄檔,間隔也不會改變。這是因為SpecialPollInterval 只對帶有 0x1 旗標的時間來源有效。另外,在以群組原則發送時間設定的環境中,本機的登錄檔變更會在下一次原則套用時被覆蓋。請透過 w32tm /query /configuration 的輸出確認各設定值的出處,若處於原則管理之下,請在「電腦設定」>「系統管理範本」>「系統」>「Windows Time Service」>「Time Providers」>「設定Windows NTP用戶端」中進行設定。

另外,透過 /manualpeerlist 指定的外部NTP,與網域中經過驗證的時間是不同的東西,由於它不會被驗證,原則上不應用於網域成員機,而是用於頂點(PDC模擬器)或非網域機器。¹

4. 精確度的話題 ── 預設能對到什麼程度、1毫秒的條件

「Windows的NTP同步,到底能對到多準」這個問題,答案會因時代而異。

Windows Server 2012 R2／Windows 8.1以前的w32time,設計目標是提供滿足Kerberos驗證要求(預設5分鐘)的精確度,以及在同一樹系內「大致準確的時間」,官方明確指出比這更嚴格的精確度要求超出了設計規格、不屬於支援範圍。⁴ 也就是說,這是一個「只要對到秒級就算符合設計」的世界。

Windows Server 2016／Windows 10 1607以後改良了演算法,預設的時鐘更新頻率也大幅提高(例如:伺服器的時鐘調整從每小時一次提升到每秒一次)。³ 結果是,只要滿足條件,1秒・50毫秒・1毫秒的精確度被定義為支援邊界。1毫秒的主要條件如下,反過來說,若環境不滿足這些條件,就不應期待能達到1毫秒。⁴

• 以精確且穩定的Stratum 1時間來源(如GPS時鐘)為頂點的NTP階層,且路徑上的所有Windows機器均為高精確度組態
• 與時間來源之間的網路延遲低於0.1毫秒,且距時間來源在Stratum 5以內・4躍點以內
• 各階層的CPU使用率(每日平均)在80%以下(在虛擬化環境中主機也需符合)

此外,像time.windows.com這樣的網際網路遠端時間來源,會受路徑不對稱與壅塞的影響,因此不能期待達到1毫秒精確度。⁷ 從實務經驗來看,以「預設的工作群組=可能相差秒級到數十秒」「妥善組態的公司內部NTP同步=數十毫秒到1秒以內」「使用專用時間來源並專門設計=毫秒級」這3個等級來把握,是比較穩妥的做法。若設備整合需要毫秒級的先後關係,就不應依賴時間同步,而應如後文所述,轉向以單側機器的時鐘來測量的設計。

5. 虛擬機器的時間 ── Hyper-V時間同步整合服務與NTP的雙重關係

虛擬機器的時間比實體機更容易出問題,原因很單純:提供時間的對象有兩套。Hyper-V來賓上的Windows,同時擁有向主機取得時間的Hyper-V時間同步整合服務(VMICTimeSync提供者),以及一般的NTP用戶端,Windows會依階層(Stratum)、根延遲、根離散度、偏移量的順序,挑選「較好的一方」。⁷

Windows Server 2016大幅改善了這個機制:VM啟動、還原時的初始時間變得準確,經過中斷延遲校正的樣本也會傳給w32time,使其相對於主機能維持約10微秒的精確度。主機回報給來賓的Stratum也變成符合實際情況的「主機Stratum+1」,加入網域的2016以後版本來賓,已不再單純依賴主機,而是會自行選擇最準確的時鐘。³

另一方面,若在網域中執行Windows Server 2012 R2以前的來賓,Hyper-V時間同步提供者有可能擾亂網域的時間同步,因此Microsoft建議停用該提供者。³

reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider /v Enabled /t REG_DWORD /d 0 /f
net stop w32time && net start w32time

關於Azure的VM也有相應整理,重點是「加入網域的VM(尤其是虛擬化的DC)應停用TimeSync、統一改用網域階層;非網域的單獨VM則維持預設的主機同步」。³ 第三方虛擬化平台(如VMware)的思路也相同,對於加入網域的來賓,建議關閉主機端的時間同步功能。³ 若出現「NTP與主機同步交替拉扯時鐘,導致日誌時間忽前忽後」的症狀,請懷疑是這種雙重關係在作祟。另外補充一項維運上的注意事項:從VM的儲存狀態還原,或剛完成即時遷移之後,時間會從偏差較大的狀態開始校正,因此還原後不久的日誌時間,尤其不能輕信。

6. 業務系統端的設計 ── 以「時間會偏差、會倒退」為前提來打造

到這裡為止談的是基礎設施端的話題,但無論把時間同步調得多完善,偏差都不會歸零。開發設備整合軟體的一方,需要以時間會偏差,也可能倒退為前提,來設計日誌與時間測量。

第一個原則是,日誌時間戳記以UTC記錄。若以本地時間記錄,時區、日光節約時間,以及各裝置之間的設定差異都會妨礙比對(這個話題在「業務應用程式的日期時間與時區」中有詳細討論)。第二個原則是,依「何時發生」與「花費多久」來區分使用不同的時鐘。

// 【陷阱】用系統時鐘測量經過時間
// 一旦w32time進行階躍校正,這個差值就可能比實際更長、更短,甚至變成負數
var start = DateTime.UtcNow;
ExecuteInspection();
var elapsed = DateTime.UtcNow - start;   // 用於逾時判斷會誤判

// 【標準做法】經過時間用Stopwatch(單調遞增時鐘)測量
long t0 = Stopwatch.GetTimestamp();
ExecuteInspection();
TimeSpan elapsed2 = Stopwatch.GetElapsedTime(t0);   // .NET 7以後。更早版本用Stopwatch.StartNew()

Stopwatch是專門用於測量經過時間的類別,它透過高解析度效能計數器(相當於QueryPerformanceCounter)計算刻度,不受系統時鐘校正的影響。⁵ 另一方面,DateTime.UtcNow本身就是系統時鐘,其解析度也取決於系統計時器(大致為0.5～15毫秒)。⁶ 逾時判斷、重試間隔、效能測量、裝置回應時間測量── 凡是處理「長度」的處理,全部交給Stopwatch這一側。

日誌中兩者都要並列記錄。讓掛鐘時間(UTC)與單調時鐘成對保存下來,之後即使區間跨越了NTP的階躍校正,也能還原出事件的順序與間隔。

public sealed class OpLog
{
    private static readonly long _baseTimestamp = Stopwatch.GetTimestamp();
    private static long _seq;

    public static void Write(string message)
    {
        long seq = Interlocked.Increment(ref _seq);
        // UTC時間(何時發生)+ 自啟動以來的單調經過毫秒數(順序與間隔)+ 序號(同一時刻內的順序)
        var line = $"{DateTime.UtcNow:yyyy-MM-dd'T'HH:mm:ss.fff'Z'}\t" +
                   $"{Stopwatch.GetElapsedTime(_baseTimestamp).TotalMilliseconds:F1}\t" +
                   $"{seq}\t{message}";
        // ... 輸出到檔案/ETW
    }
}

面向多台機器・裝置之間的日誌比對,再補充兩點。其一是,定期記錄與對方時鐘之間的偏移量。像相機、PLC這類擁有自身時鐘的裝置,往往可以透過通訊協定讀取裝置時間,因此在應用程式啟動時以及定期(例如每小時一次)將「PC的UTC時間與裝置時間之差」記入日誌。這相當於w32tm /stripchart的裝置版,故障發生後就能機械式地完成「這段期間,裝置日誌的時間要加上+12.3秒的校正來讀取」這類比對。其二是,讓事件記錄・ETW端的記錄與自建日誌的時間體系保持一致(參見「Windows事件記錄・ETW入門」)。在當機時的證據設計(「當機時保留日誌與傾印檔的設計」),以及像相機通訊中斷這類由網路引發的故障調查(「TCP重送導致工業相機通訊中斷」)中,時間體系是否一致,會讓調查所需時間相差一個數量級。

在離線的工廠區域網路(未連上網際網路)中,由於無法連到time.windows.com,在區域網路內架設本地NTP伺服器,讓所有裝置都對齊到它是標準做法。若有GPS時鐘當然理想,但即使沒有,只要能做到「絕對時間或許有些許誤差,但所有裝置都對齊到同一個基準」,日誌比對的目的也大致能夠達成。對於基準伺服器,還可以考慮調整LocalClockDispersion── 它決定了在無法與外部同步期間自我申報的精確度。²

7. 依環境劃分的判斷表

8. 總結

• Windows的時間由w32time管理,在網域中是以PDC模擬器為頂點的階層同步,在工作群組中預設是與time.windows.com的低頻率同步。數十秒的偏差不是故障,而是預設值帶來的結果。
• 調查應從用 w32tm /query /status 確認同步來源與最後同步時間、用 w32tm /stripchart 實測與對方的差值開始。明確指定同步對象用 /config /manualpeerlist,立即生效用 /resync。
• w32time對小幅偏差進行滑動校正,對大幅偏差進行階躍校正。請務必記住:系統時鐘也可能往後跳,而且一旦超過上限就不會被校正。
• 預設設定的精確度目標,歷來只是滿足「Kerberos的5分鐘」這個程度。毫秒級精確度是Windows Server 2016以後版本,在滿足精確時間來源、延遲、躍點數、CPU負載等條件時的支援範圍。
• 虛擬機器擁有主機同步與NTP兩套體系。加入網域的VM原則上應統一為網域同步(舊版作業系統的來賓需停用VMICTimeProvider),單獨VM原則上維持主機同步。
• 應用程式端要區分使用:時間戳記用UTC,經過時間用Stopwatch,並定期記錄與裝置自身時鐘之間的偏移量。做到這3點,就能從「分不清誰先誰後」的故障調查困境中脫身。

相關文章

• 業務應用程式的日期時間與時區 ── 從 DateTime 的陷阱到 UTC 儲存原則、測試設計
• Windows 應用程式因程式錯誤的例外掉下也要確實留下日誌 - 不賭 in-process 的設計與 WER / 最終日誌 / 監視程序的最佳實踐
• Windows 事件記錄・ETW 入門 ── 讓業務應用程式的日誌搭上 OS 標準機制
• TCP 重送讓工業相機通訊卡幾秒時 - RFC1323 timestamp 與重送等待的切分
• 工作排程器的工作不執行、以 0x1 結束 ── 原因排查與安全的維運設計
• 業務應用程式的日本年號・國定假日・結算日處理 ── 抗改元設計與 JapaneseCalendar・營業日計算實務

相關諮詢領域

合同會社小村軟體承接「裝置與PC的日誌時間對不上,無法確定故障先後關係」之類的調查諮詢、工廠區域網路・設備整合環境的時間同步設計,以及包含逾時與時間測量相關缺陷在內的設備整合軟體開發與改善。

• 故障調查・原因分析
• 技術諮詢・設計審查
• 軟即時Windows應用程式開發
• 聯絡我們

參考連結

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

PC的日誌與裝置的日誌時間對不上,首先應該確認什麼？

首先在PC端執行 w32tm /query /status,確認「來源」(正在與何處同步)與「最後成功同步時間」。如果來源顯示為 Local CMOS Clock,或最後同步是好幾天前,代表這台PC實際上並未與任何對象同步。接著用 w32tm /stripchart /computer:對方 /dataonly 實測與對方(伺服器或裝置的NTP連接埠)之間的時間差,以數值掌握是哪一方偏差了多少。若裝置端有自己的時鐘,可透過裝置的時間設定畫面或通訊讀取裝置時間,記錄它與PC時間的差值,這在事後比對過去的日誌時也用得上。

工作群組環境的Windows,大約多久同步一次時間？

未加入網域的Windows預設會與time.windows.com同步,但頻率設定得相當低。登錄檔預設的SpecialPollInterval在獨立(standalone)組態下為604,800秒(1週),即使是Windows 10用戶端,大約也只有一天一次。PC內建時鐘每天出現數秒到數十秒的偏差並不罕見,以這種頻率是無法期待有足以應付業務日誌比對之精確度的。在需要日誌時間精確度的現場,標準做法是用 w32tm /config /manualpeerlist 指定內部的NTP伺服器,並縮短SpecialPollInterval。

Hyper-V上的虛擬機器,時間應該以主機還是NTP為準？

Hyper-V的來賓有兩個時間提供者:向主機取得時間的Hyper-V時間同步整合服務(VMICTimeSync),以及一般的NTP用戶端,Windows會依階層(Stratum)等基準選擇較好的那一個。加入網域的來賓,原則上是與網域階層(DC)同步;若主機/來賓的組合都是Windows Server 2016以後的版本,兩者已改善為可以共存。若在網域中使用Windows Server 2012 R2以前的來賓,Microsoft的建議是停用VMICTimeProvider,統一改用網域同步。若是工作群組下的單獨VM,維持預設的主機同步是最簡單也最可靠的做法。

在網域環境中,時間若出現大幅偏差會發生什麼事？

用於Active Directory驗證的Kerberos,預設要求用戶端與伺服器之間的時間差在5分鐘以內。一旦超過這個範圍就會驗證失敗,共用資料夾的存取、群組原則的套用等網域基本功能都會停止運作。加入網域的PC預設會依循以DC、最終以樹系根的PDC模擬器為頂點的階層進行同步,因此通常不會出現這麼大的偏差。反過來說,若PDC模擬器本身沒有與外部的精確時間來源同步,整個網域就會「一起錯到同一個時間」,因此確認頂點的設定非常重要。

為什麼不應該用DateTime.UtcNow來測量經過時間？

因為DateTime.UtcNow讀取的是系統時鐘,會直接受到w32time校正的影響。當時間差較大時,w32time不會採用漸進校正(slew),而是直接設定時鐘(step),此時時間可能往前跳,也可能往後跳。也就是說,用UtcNow相減所測得的經過時間,實際上可能變長、變短,甚至變成負數。測量經過時間或逾時判斷時,應該使用與系統時鐘無關、單調遞增的Stopwatch(或Stopwatch.GetTimestamp),並把UtcNow定位為專門記錄「何時發生」的用途,這樣才安全。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。