Stopwatch.Gettimestamp 是否會翻轉？ 還是回滾？

Question

在使用 Stopwatch.GetTimestamp() 時，我們發現如果記錄返回值，然后繼續調用它並與之前的返回值進行比較，它最終會但不可預測地返回一個小於原始值的值。

這是預期的行為嗎？

在生產代碼中這樣做的目的是獲得微秒精確的系統時間。

該技術涉及分別調用 DateTime.UtcNow 和調用 Stopwatch.GetTimestamp() 作為 originalUtcNow 和 originalTimestamp。

從那時起，應用程序只需調用 Stopwatch.GetTimestamp() 並使用 Stopwatch.Frequency 計算與 originalTimestamp 變量的差異，然后將該差異添加到 originalUtcNow。

然后，瞧……高效且准確的微秒 DateTime。

但是，我們發現有時 Stopwatch.GetTimestamp() 會返回較低的數字。

它很少發生。 我們的想法是在發生這種情況時簡單地“重置”並繼續。

然而，它讓我們懷疑 Stopwatch.GetTimestamp() 的准確性或懷疑 .Net 庫中存在錯誤。

如果你能對此有所了解，請這樣做。

僅供參考，根據當前的時間戳值、頻率和 long.MaxValue，除非是硬件問題，否則它在我們的生命周期內似乎不太可能翻轉。

編輯：我們現在正在“每個線程”計算這個值，然后“鉗制它”以觀察內核之間的跳轉以重置它。

Answer 1

您可能會及時獲得跳躍，因為您的線程正在跳躍核心。 請參閱此頁面上的“注釋”： http : //msdn.microsoft.com/en-us/library/ebf7z0sw.aspx

Answer 2

秒表類的行為會因系統而異，具體取決於硬件支持。

請參閱： http : //msdn.microsoft.com/en-us/library/system.diagnostics.stopwatch.ishighresolution.aspx

另外，我相信底層等效的 win32 調用（ QueryPerformanceCounter ）包含有用的文檔： http : //msdn.microsoft.com/en-us/library/windows/desktop/ms644904 ( v=vs.85 ) .aspx

Answer 3

我不完全知道關於向后運行（這聽起來像是向后的一個小變化），但到目前為止我已經經歷了三倍，即 Stopwatch.GetTimestamp() 的值變化如此之大，以至於在一些進一步的計算中會導致溢出異常形式大約是這樣的：
(Stopwatch.GetTimestamp() - ProgramStartStopwatchTimestamp) * n
其中n是一個很大的值，但足夠小，如果秒表沒有大幅跳動，那么程序可以運行多年而不會出現溢出異常。 另請注意，這些異常發生在程序啟動數小時后，因此問題不僅僅是秒表在啟動后立即向后跑了一點。 它只是跳到了完全不同的范圍，無論朝哪個方向。

關於秒表滾動，在上述一種情況下，它（不是差異，而是秒表）獲得了 0xFF4 的值？ ？？？ ？？？ ????，所以它跳到了一個非常接近翻滾的范圍。 多次重新啟動程序后，這個新范圍仍然有效。 如果考慮到無論如何都需要處理跳躍，那再重要的話......

如果還需要確定時間戳記在哪個內核上，那么了解執行內核編號可能會有所幫助。 為此，有名為GetCurrentProcessorNumber （自 Server 2003 和 Vista 起可用）和GetCurrentProcessorNumberEx （自 Server 2008 R2 和 Windows 7 起可用）的函數。 另請參閱此問題的答案以獲取更多選項（包括 Windows XP）。
請注意，調度程序可以隨時更改內核編號。 但是當在讀取秒表時間戳之前讀取內核編號，並且之后，內核編號保持不變，那么也許可以假設秒表讀取也是在這個內核上執行的......

Answer 4

為了具體回答“ Stopwatch.GetTimestamp()多久翻轉一次？”這個高級問題， 微軟的回答是：

從最近一次系統啟動算起不少於 100 年，根據所使用的底層硬件計時器，時間可能更長。 對於大多數應用程序，翻轉不是問題。