计时器精度:c clock() 与 WinAPI 的 QPC 或 timeGetTime() [英] timer accuracy: c clock( ) vs. WinAPI's QPC or timeGetTime( )

问题描述

我想描述软件计时器的准确性.我不太关心它的准确度，但确实需要知道准确度是多少.

I'd like to characterize the accuracy of a software timer. I'm not concerned so much about HOW accurate it is, but do need to know WHAT the accuracy is.

我研究了 c 函数clock()，以及WinAPI 的函数QPC 和timeGetTime，我知道它们都依赖于硬件.

I've investigated c function clock(), and WinAPI's function QPC and timeGetTime, and I know that they're all hardware dependent.

我正在测量一个可能需要大约 5-10 秒的过程，我的要求很简单:我只需要 0.1 秒的精度(分辨率).但我确实需要知道准确度是多少，最坏的情况.

I'm measuring a process that could take around 5-10 seconds, and my requirements are simple: I only need 0.1 second precision (resolution). But I do need to know what the accuracy is, worst-case.

虽然更高的准确性是首选，但我宁愿知道准确性很差(500 毫秒)并解释它，也不愿相信准确性更好(1 毫秒)但无法记录它.

while more accuracy would be preferred, I would rather know that the accuracy was poor (500ms) and account for it, than to believe that the accuracy was better (1 mS) but not be able to document it.

有人对如何表征软件时钟精度有任何建议吗?

Does anyone have suggestions on how to characterize software clock accuracy?

谢谢

推荐答案

您需要区分准确性、分辨率和延迟.

You'll need to distinguish accuracy, resolution and latency.

clock()、GetTickCount 和 timeGetTime() 来自校准的硬件时钟.分辨率不是很好，它们由时钟滴答中断驱动，默认情况下每秒滴答 64 次或每 15.625 毫秒一次.您可以使用 timeBeginPeriod() 将其降低到 1.0 毫秒.精度非常好，时钟是从NTP服务器校准的，你通常可以指望它在一个月内不会超过一秒.

clock(), GetTickCount and timeGetTime() are derived from a calibrated hardware clock. Resolution is not great, they are driven by the clock tick interrupt which ticks by default 64 times per second or once every 15.625 msec. You can use timeBeginPeriod() to drive that down to 1.0 msec. Accuracy is very good, the clock is calibrated from a NTP server, you can usually count on it not being off more than a second over a month.

QPC 具有更高的分辨率，在某些机器上总是优于一微秒和半纳秒.然而，它的准确性很差，时钟源是从某处芯片组拾取的频率.它未经校准，具有典型的电子容差.仅用于短时间间隔.

QPC has a much higher resolution, always better than one microsecond and as little as half a nanosecond on some machines. It however has poor accuracy, the clock source is a frequency picked up from the chipset somewhere. It is not calibrated and has typical electronic tolerances. Use it only to time short intervals.

当您处理时间问题时，延迟是最重要的因素.如果您不能足够快地阅读它，那么您就没有使用高度准确的计时源.当您在受保护模式操作系统上以用户模式运行代码时，这始终是一个问题.总是有比你的代码运行优先级更高的代码.特别是设备驱动程序是麻烦制造者，尤其是视频和音频驱动程序.您的代码也会被换出 RAM，需要页面错误才能重新加载.在负载很重的机器上，无法运行数百毫秒的代码并不罕见.您需要在设计中考虑这种故障模式.如果您需要保证亚毫秒级的精度，那么只有具有实时优先级的内核线程才能满足您的需求.

Latency is the most important factor when you deal with timing. You have no use for a highly accurate timing source if you can't read it fast enough. And that's always an issue when you run code in user mode on a protected mode operating system. Which always has code that runs with higher priority than your code. Particularly device drivers are trouble-makers, video and audio drivers in particular. Your code is also subjected to being swapped out of RAM, requiring a page-fault to get loaded back. On a heavily loaded machine, not being able to run your code for hundreds of milliseconds is not unusual. You'll need to factor this failure mode into your design. If you need guaranteed sub-millisecond accuracy then only a kernel thread with real-time priority can give you that.

一个相当不错的计时器是您从 timeSetEvent() 获得的多媒体计时器.它旨在为需要可靠计时器的程序提供良好的服务.你可以让它在 1 毫秒内打勾，它会在可能的情况下赶上延迟.请注意，它是一个异步计时器，回调是在单独的工作线程上进行的，因此您必须小心处理适当的线程同步.

A pretty decent timer is the multi-media timer you get from timeSetEvent(). It was designed to provide good service for the kind of programs that require a reliable timer. You can make it tick at 1 msec, it will catch up with delays when possible. Do note that it is an asynchronous timer, the callback is made on a separate worker thread so you have to be careful taking care of proper threading synchronization.

这篇关于计时器精度:c clock() 与 WinAPI 的 QPC 或 timeGetTime()的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！