Does Stopwatch.Gettimestamp có bao giờ vượt qua? Hay quay trở lại?

Question

Khi sử dụng Stopwatch.GetTimestamp(), chúng tôi thấy rằng nếu bạn ghi lại giá trị trả về và sau đó tiếp tục gọi nó và so sánh với giá trị trả về trước đó, cuối cùng sẽ không thể trả về giá trị nhỏ hơn giá trị ban đầu.

Hành vi này có được mong đợi không?

Mục đích của việc này trong mã sản xuất là có thời gian sytem chính xác đến một micro giây.

Kỹ thuật này liên quan đến việc gọi DateTime.UtcNow và cũng gọi hàm Stopwatch.GetTimestamp() dưới dạng originalUtcNow và originalTimestamp tương ứng.

Từ thời điểm đó trở đi, ứng dụng chỉ cần gọi Stopwatch.GetTimestamp() và sử dụng Stopwatch.Frequency nó tính toán sự khác biệt từ biến originalTimestamp và sau đó thêm sự khác biệt đó vào originalUtcNow.

Sau đó, Thì đấy ... một micro giây hiệu quả và chính xác DateTime.

Nhưng, chúng tôi thấy rằng đôi khi đồng hồ bấm giờ.GetTimestamp() sẽ trả lại số thấp hơn.

Điều đó xảy ra khá hiếm khi. Suy nghĩ của chúng tôi là chỉ cần "đặt lại" khi điều đó xảy ra và tiếp tục.

TUY NHIÊN, điều này khiến chúng tôi nghi ngờ tính chính xác của Stopwatch.GetTimestamp() hoặc nghi ngờ có lỗi trong thư viện .Net.

Nếu bạn có thể làm sáng tỏ điều này, vui lòng thực hiện.

FYI, dựa trên giá trị dấu thời gian hiện tại, tần suất và độ dài.MaxValue dường như không chắc sẽ cuộn qua trong suốt cuộc đời trừ khi đó là vấn đề phần cứng.

EDIT: Chúng tôi hiện đang tính toán giá trị này "cho mỗi chuỗi" và sau đó "kẹp" để xem các bước nhảy giữa các lõi để đặt lại.

Answer 1

Có thể bạn nhận được thời gian nhảy vì luồng của bạn là lõi nhảy. Xem "ghi chú" trên trang này: http://msdn.microsoft.com/en-us/library/ebf7z0sw.aspx

Answer 2

Hành vi của lớp Đồng hồ bấm giờ sẽ thay đổi từ hệ thống đến hệ thống tùy thuộc vào hỗ trợ phần cứng.

Xem: http://msdn.microsoft.com/en-us/library/system.diagnostics.stopwatch.ishighresolution.aspx

Ngoài ra, tôi tin rằng tiềm ẩn tương đương win32 gọi (QueryPerformanceCounter) chứa tài liệu hữu ích: http://msdn.microsoft.com/en-us/library/windows/desktop/ms644904(v=vs.85).aspx

Answer 3

Tôi không biết chính xác về về việc chạy ngược (mà âm thanh như một nhỏ thay đổi ngược), nhưng tôi đã trải qua ba lần rằng giá trị của Stopwatch.GetTimestamp() có thể thay đổi rất lớn đến nỗi nó gây ra các ngoại lệ tràn tràn trong một số tính toán thêm về biểu mẫu như thế này:
(Stopwatch.GetTimestamp() - ProgramStartStopwatchTimestamp) * n
nơi n là một số giá trị lớn, nhưng đủ nhỏ rằng nếu Stopwatch không được nhảy xung quanh vô cùng, sau đó chương trình có thể chạy năm mà không cần phải tràn ngoại lệ. Cũng lưu ý rằng những ngoại lệ này xảy ra nhiều giờ sau khi chương trình bắt đầu, do đó, vấn đề không chỉ là Đồng hồ bấm giờ chạy ngược lại một chút ngay sau khi bắt đầu.Nó chỉ nhảy đến phạm vi hoàn toàn khác, theo bất kỳ hướng nào.

Về Đồng hồ bấm giờ được chuyển sang, trong một trong các trường hợp trên nó (không phải là sự khác biệt, nhưng Đồng hồ bấm giờ) có được giá trị của một cái gì đó là la 0xFF4? ???? ???? ????, vì vậy nó nhảy đến một phạm vi rất gần với việc lăn qua. Sau khi khởi động lại chương trình nhiều lần, phạm vi mới này vẫn liên tục có hiệu lực. Nếu điều đó quan trọng nữa, cần xem xét việc cần phải xử lý các bước nhảy ...

Nếu cần xác định xem dấu thời gian nào đã được thực hiện thì có thể sẽ giúp bạn biết được số lõi. Với mục đích này, có các chức năng gọi là GetCurrentProcessorNumber (có sẵn từ Server 2003 và Vista) và GetCurrentProcessorNumberEx (có sẵn từ Server 2008 R2 và Windows 7). Xem thêm this question's answers để biết thêm tùy chọn (bao gồm Windows XP).
Lưu ý rằng số lõi có thể được thay đổi bởi bộ lập lịch bất kỳ lúc nào. Nhưng khi người ta đọc số lõi trước khi đọc dấu thời gian đồng hồ bấm giờ, và sau đó, và số lõi vẫn giữ nguyên, thì có lẽ người ta có thể giả định rằng đồng hồ bấm giờ cũng được thực hiện trên lõi này ...