在Windows微秒级时间戳 [英] Microsecond resolution timestamps on 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.)
有是的 实现了不断更新，高分辨率的时间提供窗户 的，但它似乎并不牢固。的 当微秒关系 的看起来很大，但它不提供下载了。
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.
我也看了看维基百科文章的 时间戳计数器 的这很有趣，但没有多大用处。
I also looked at the Wikipedia article Time Stamp Counter which is interesting, but not that useful.
如果答案只是做这与BSD或Linux的，这是一个极大的方便，这很好，但我想确认一下，并得到一些解释，这是为什么这么难在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...
推荐答案
我相信这仍然是有用的：<一href=\"http://web.archive.org/web/20140213124142/http://msdn.microsoft.com/en-us/windows/hardware/gg463347.aspx\"相对=nofollow>系统内部：指南提供多媒体计时器支持
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 时，特别是在多处理器（/多核）系统：它会使用 HPET 在Windows＆NBSP; Vista和更高版本（如果可用）或 ACPI / PM计时器。
在我的系统（Windows和NBSP; 7 64位，双核AMD）计时器在14.31818＆NBSP运行;兆赫
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 ，然后在偷看 Stopwatch.Frequency 。这将使内部必要的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 启动开关仍然存在。如果失败为好，因为系统不从奔腾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.
的 游戏时间和多核处理器 的是如何正确地使用它们的建议。请考虑它现在的五类的岁了，在那个时候更少的系统是完全符合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).
轶事告诉，8年前，情况在极少数情况下的不同。 （使一个有趣的阅读，围绕开发设计的短板的工作，并抨击芯片设计者为了公平起见，它可能是相同的方式反之亦然： - ）
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. :-)
这篇关于在Windows微秒级时间戳的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
