中等时间间隔的准确时间增量：GetTickCount64 vs QueryPerformanceCounter

Question

关于在 Windows 上获取单调时间的机制及其各种陷阱和陷阱有很多问题（here、here、here）。我对主要选项的准确性（而不是精度）特别感兴趣。

我希望在一台机器上测量经过的时间，时间大约是几分钟到一个小时。到目前为止我所知道的：

• QueryPerformanceCounter 非常适合短时间间隔，但 QPF 可能有大约 500PPM 的错误，这意味着一个小时内有 2 秒的错误。
  • 更令人担忧的是，即使在相当新的处理器上，folks are seeing QPC misbehavior。
  • Microsoft 建议将 QPC 用于短期持续时间测量。但短期没有以任何绝对数字来定义。
• GetTickCount64 经常被认为是 QPC 的一个不错且可靠、不太精确的替代方案。
  • 我没有找到任何关于 GetTickCount64 准确性的详细信息。虽然它不如 QPC 精确，但它的准确性如何比较？一个多小时后我可能会遇到什么样的错误？
  • 有些程序使用timeBeginPeriod 来调整它的分辨率，虽然我认为这不会影响准确性？
  • 文档讨论了 GetTickCount64 的分辨率如何不受 GetSystemTimeAdjustment 函数所做的调整的影响。希望这意味着 GetTickCount64 是单调的并且从未调整过？这是不寻常的措辞...
• 如果我通过SetSystemTimeAdjustment 禁用自动时间调整，GetSystemTimePreciseAsFileTime 是同一机器时间增量的一个选项。它由 QPC 提供支持。直接在 QPC 上使用它有什么好处吗？ （也许它会使用清理或线程关联技巧来避免直接 QPC 调用遇到的一些问题？）

Answer 1

我发现了一个 SO QA linked to this blog post，它对阅读特别有用。虽然它没有直接回答我的问题，但它深入探讨了 QPC 在 Windows 上的工作原理，以及常见的 linux 单调时间如何基本使用相同的东西。

要点是当现代硬件上的不变 TSC 可用时，它们都使用rtdsc。