问题
Stopwatch.GetTimeStamp() may return different timing results on different processors because of bugs in the BIOS or the Hardware Abstraction Layer.
Does anyone know what these bugs hold in store in concrete terms?
- Could timestamps on different processors potentially be totally unrelated - or would they be only off by some small amount (sub-milliseconds?) at most?
- Could numbers on different processors drift apart over time - which then would in effect lead to the aforementioned "timestamps totally unrelated"? (I would think different frequencies on different processors might do this)
回答1:
that is because it is written in the doc:
The Stopwatch class assists the manipulation of timing-related performance counters within managed code. Specifically, the Frequency field and GetTimestamp method can be used in place of the unmanaged Win32 APIs QueryPerformanceFrequency and QueryPerformanceCounter.
And therefore comes the alea of using the performance counter.
Windows implementation has at least 2 possible sources for performance counter, the HPET, the RDTC, and this is determined by ACPI. However, ACPI is mostly the problem, most manufacturers are implementing it badly therefore sometimes the decision to ignore completely the ACPI advice and do something else instead.
When using RDTC, thread migration over another CPU will result in slightly negative results if luck is not with you and that you measure a super small time anyway. But it can happen.
来源：https://stackoverflow.com/questions/24051968/stopwatch-gettimestamp-on-multiprocessors