Windows 上的微秒分辨率时间戳
如何在 Windows 上获得微秒分辨率的时间戳?
How do I get microsecond resolution timestamps on Windows?
我正在寻找比 QueryPerformanceCounter 和 QueryPerformanceFrequency 更好的东西(这些只能为您提供自启动以来经过的时间，如果在不同线程上调用它们，则不一定准确- 也就是说，QueryPerformanceCounter 在不同的 CPU 上可能返回不同的结果.也有一些处理器为了省电而调整频率，这显然并不总是反映在他们的 QueryPerformanceFrequency结果.)
I am loking for something better than QueryPerformanceCounter and QueryPerformanceFrequency (these can only give you an elapsed time since boot and are not necessarily accurate if they are called on different threads - that is, QueryPerformanceCounter may return different results on different CPUs. There are also some processors that adjust their frequency for power saving, which apparently isn't always reflected in their QueryPerformanceFrequency result.)
为Windows，但它似乎并不稳固.当微秒很重要时 看起来不错，但不能再下载了.
There is Implement a Continuously Updating, High-Resolution Time Provider for Windows, but it does not seem to be solid. When microseconds matter looks great, but it's not available for download any more.
另一个资源是在 Windows XP 下获取准确的时间戳，但它需要许多步骤，运行一个辅助程序以及一些初始化程序，我不确定它是否适用于多个 CPU.
Another resource is Obtaining Accurate Timestamps under Windows XP, but it requires a number of steps, running a helper program plus some init stuff also, I am not sure if it works on multiple CPUs.
我还看了维基百科文章Time Stamp Counter很有趣，但没那么有用.
I also looked at the Wikipedia article Time Stamp Counter which is interesting, but not that useful.
如果答案只是用 BSD 或 Linux 来做这件事，那会容易得多，那很好，但我想确认这一点，并得到一些解释，为什么这在 Windows 中如此困难而在 Windows 中如此容易Linux 和 BSD.它是相同的精美硬件...
If the answer is just do this with BSD or Linux, it's a lot easier and that's fine, but I would like to confirm this and get some explanation as to why this is so hard in Windows and so easy in Linux and BSD. It's the same fine hardware...
推荐答案
我相信这个还是有用的:系统内部:提供多媒体定时器支持的指南.
I believe this is still useful: System Internals: Guidelines For Providing Multimedia Timer Support.
它很好地解释了各种可用的计时器及其限制.可能你的大敌不是分辨率，而是延迟.
It does a good job of explaining the various timers available and their limitations. It might be that your archenemy will not so much be resolution, but latency.
QueryPerformanceCounter 不会总是在CPU速度.事实上，它可能会尽量避免 RDTSC，尤其是在多处理器(/multi-core) 系统:它将在 Windows Vista 上使用 HPET稍后如果它可用或 ACPI/PM 计时器.在我的系统(Windows 7 x64，双核 AMD)上，计时器以 14.31818MHz 运行.
QueryPerformanceCounter will not always run at CPU speed. In fact, it might try to avoid RDTSC, especially on multi-processor(/multi-core) systems: it will use the HPET on Windows Vista and later if it is available or the ACPI/PM timer. On my system (Windows 7 x64, dual core AMD) the timer runs at 14.31818 MHz.
早期系统也是如此:
默认情况下，Windows Server 2003 Service Pack 2 (SP2) 对所有多处理器 APIC 或 ACPI HAL 使用 PM 计时器，除非确定 BIOS 是否支持 APIC 或 ACPI HAL 的检查过程失败."
By default, Windows Server 2003 Service Pack 2 (SP2) uses the PM timer for all multiprocessor APIC or ACPI HALs, unless the check process to determine whether the BIOS supports the APIC or ACPI HALs fails."
问题是，当检查失败时.这只是意味着您的计算机/BIOS 以某种方式损坏了.然后您可以修复您的 BIOS(推荐)，或者至少切换到使用 ACPI 计时器 (/usepmtimer) 暂时.
The problem is, when the check fails. This simply means that your computer/BIOS is broken in a way. Then you might either fix your BIOS (recommended), or at least switch to using the ACPI timer (/usepmtimer) for the time being.
从 C# 很容易 - 没有 P/Invoke - 检查高分辨率Stopwatch.IsHighResolution 然后查看 秒表.频率.它将在内部进行必要的 QueryPerformanceCounter 调用.
It is easy from C# - without P/Invoke - to check for high-resolution timer support with Stopwatch.IsHighResolution and then peek at Stopwatch.Frequency. It will make the necessary QueryPerformanceCounter call internally.
还要考虑的是，如果计时器坏了，整个系统将发生严重破坏，并且通常会表现得很奇怪，报告经过的时间为负数、速度变慢等 - 而不仅仅是您的应用程序.
Also consider that if the timers are broken, the whole system will go havoc and in general, behave strangely, reporting negative elapsed times, slowing down, etc. - not just your application.
这意味着您实际上可以依赖 QueryPerformanceCounter.
This means that you can actually rely on QueryPerformanceCounter.
... 与普遍看法相反，QueryPerformanceFrequency() "系统运行时不能更改".
... and contrary to popular belief, QueryPerformanceFrequency() "cannot change while the system is running".
作为 QueryPerformanceCounter 上的文档() 指出，调用哪个处理器无关紧要"――事实上，只有在 APIC/ACPI 检测失败并且系统求助于使用TSC.这是一个不应该发生的度假胜地.如果它发生在较旧的系统上，则制造商可能会进行 BIOS 更新/驱动程序修复.如果没有，/usepmtimer 启动开关仍然存在.如果这也失败了，因为系统除了 Pentium TSC 之外没有合适的计时器，您实际上可能会考虑弄乱线程关联 - 即使这样，页面的社区内容"区域中其他人提供的示例是误导，因为它具有不可忽略的开销，因为它在每次启动/停止调用时都设置了线程关联 - 这会引入相当大的延迟，并可能首先削弱使用高分辨率计时器的好处.
As the documentation on QueryPerformanceCounter() states, "it should not matter which processor is called" - and in fact the whole hacking around with thread affinity is only needed if the APIC/ACPI detection fails and the system resorts to using the TSC. It is a resort that should not happen. If it happens on older systems, there is likely a BIOS update/driver fix from the manufacturer. If there is none, the /usepmtimer boot switch is still there. If that fails as well, because the system does not have a proper timer apart from the Pentium TSC, you might in fact consider messing with thread affinity - even then, the sample provided by others in the "Community Content" area of the page is misleading as it has a non-negligible overhead due to setting thread affinity on every start/stop call - that introduces considerable latency and likely diminishes the benefits of using a high resolution timer in the first place.
游戏计时和多核处理器 是关于如何正确使用它们的建议.请考虑到它现在已经5 年了，当时完全符合/支持 ACPI 的系统更少――这就是为什么在抨击它时，这篇文章详细介绍了 TSC 以及如何工作通过保持仿射线程来解决其局限性.
Game Timing and Multicore Processors is a recommendation on how to use them properly. Please consider that it is now five years old, and at that time fewer systems were fully ACPI compliant/supported - that is why while bashing it, the article goes into so much detail about TSC and how to work around its limitations by keeping an affine thread.
我相信如今要找到具有零 ACPI 支持且没有可用 PM 计时器的普通 PC 是一项相当艰巨的任务.最常见的情况可能是 BIOS 设置，当 ACPI 支持设置不正确时(有时令人遗憾的是出厂默认设置).
I believe it is a fairly hard task nowadays to find a common PC with zero ACPI support and no usable PM timer. The most common case is probably BIOS settings, when ACPI support is incorrectly set (sometimes sadly by factory defaults).
轶事告诉 八年前，在极少数情况下情况有所不同.(读起来很有趣，开发人员在解决设计缺点"并抨击芯片设计人员.公平地说，反之亦然.:-)
Anecdotes tell that eight years ago, the situation was different in rare cases. (Makes a fun read, developers working around design "shortcomings" and bashing chip designers. To be fair, it might be the same way vice versa. :-)
相关文章