.NET 中最准确的计时器?
运行以下(稍微伪)代码会产生以下结果。我对计时器的不准确程度感到震惊(每个Tick
增加约14ms)。
还有更准确的吗?
void Main()
{
var timer = new System.Threading.Timer(TimerCallback, null, 0, 1000);
}
void TimerCallback(object state)
{
Debug.WriteLine(DateTime.Now.ToString("ss.ffff"));
}
Sample Output:
...
11.9109
12.9190
13.9331
14.9491
15.9632
16.9752
17.9893
19.0043
20.0164
21.0305
22.0445
23.0586
24.0726
25.0867
26.1008
27.1148
28.1289
29.1429
30.1570
31.1710
32.1851
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(11)
我也上过一堂课,精确到1ms。我从论坛获取了 Hans Passant 的代码
<一href="https://social.msdn.microsoft.com/Forums/en-US/6cd5d9e3-e01a-49c4-9976-6c6a2f16ad57/1-millisecond-timer"> https://social.msdn.microsoft.com/Forums/en-US/6cd5d9e3-e01a-49c4-9976-6c6a2f16ad57/1-millisecond-timer
并将其包装在一个类中,以便于在表单中使用。如果需要,您可以轻松设置多个计时器。在下面的示例代码中我使用了 2 个计时器。我已经测试过并且工作正常。
I also have witten a class which is accurate to 1ms. I took Hans Passant's code from forum
https://social.msdn.microsoft.com/Forums/en-US/6cd5d9e3-e01a-49c4-9976-6c6a2f16ad57/1-millisecond-timer
and wrapped it in a class for ease of use in your Form. You can easily set up multiple timers if you want. In the example code below I have used 2 timers. I have tested it and it works ok.
我认为其他答案未能解决为什么OP代码的每次迭代需要14ms的时间;这不是,因为系统时钟不精确(并且
DateTime.Now
并不是不准确,除非您关闭了 NTP 服务或设置了错误的时区或其他愚蠢的事情!只是不精确)。精确的计时器
即使系统时钟不精确(使用
DateTime.Now
,或者将太阳能电池连接到 ADC 来判断太阳在天空中的高度,或者划分峰值之间的时间潮汐,或...),遵循此模式的代码平均将具有零转换(它将非常准确,平均刻度之间正好一秒):(如果您复制并粘贴此内容,请注意情况下你的tick 代码的执行时间比
interval
更长,我将把它作为练习,让读者找到简单的方法来使其跳过nextTick
所需的节拍数。 > 降落在未来)不准确的计时器
我猜测微软的 System.Threading.Timer 实现遵循了这种模式。即使使用完全精确和完全准确的系统计时器,这种模式也总是会发生变化(因为即使只是添加操作也需要时间来执行):
因此,对于可能有兴趣滚动自己的计时器的人,不要遵循第二种模式。
精确的时间测量
正如其他发帖者所说,
Stopwatch
类为时间测量提供了很好的精度,但对于准确性没有任何帮助,如果遵循了错误的模式。但是,正如 @Shahar 所说,你不可能一开始就得到一个完全精确的计时器,所以如果您追求的是完美的精度,您就需要重新思考。免责声明
请注意,Microsoft 并没有过多谈论 的内部结构
System.Threading.Timer
类,所以我有根据地推测它,但如果它像鸭子一样嘎嘎叫,那么它可能是一只鸭子。另外,我意识到这已经有好几年了,但它仍然是一个相关的(我认为尚未回答的)问题。编辑:更改了@Shahar答案的链接
编辑:微软在网上有很多东西的源代码,包括
System.Threading.Timer
,适合任何有兴趣了解 Microsoft 如何实现该 slew-y 计时器的人。I think the other answers are failing to address why there's 14ms slew through each iteration of the OP's code; it's not because of an imprecise system clock (and
DateTime.Now
is not inaccurate, unless you've turned off NTP services or have the wrong time zone set or something silly! It's only imprecise).Accurate timer
Even with an imprecise system clock (making use of
DateTime.Now
, or having a solar cell hooked up to an ADC to tell how high the sun is in the sky, or dividing the time between peak tides, or ...), code following this pattern will have an average of zero slew (it will be perfectly accurate with exactly one second between ticks on average):(If you're copying-and-pasting this, watch out for cases where your tick code takes longer than
interval
to execute. I'll leave it as an exercise for the reader to find the easy ways to make this skip as many beats as it takes fornextTick
to land in the future)Inaccurate timer
I'm guessing that Microsoft's implementation of
System.Threading.Timer
follows this kind of pattern instead. This pattern will always have slew even with a perfectly precise and perfectly accurate system timer (because it takes time to execute even just the add operation):So for folks who might be interested in rolling your own timer, don't follow this second pattern.
Precise time measurement
As other posters have said, the
Stopwatch
class gives great precision for time measurement, but doesn't help at all with accuracy if the wrong pattern is followed. But, as @Shahar said it's not like you're ever going to get a perfectly-precise timer to begin with, so you need to rethink things if perfect precision is what you're after.Disclaimers
Note that Microsoft doesn't talk much about the internals of the
System.Threading.Timer
class so I'm educatedly speculating about it, but if it quacks like a duck then it's probably a duck. Also, I realize this is several years old, but it's still a relevant (and I think unanswered) question.Edit: Changed link to @Shahar's answer
Edit: Microsoft has source code for a lot of stuff online, including
System.Threading.Timer
, for anyone who is interested in seeing how Microsoft implemented that slew-y timer.几年后,但是这里< /a> 是我想出的。它会自行对齐,并且通常精确到 1 毫秒以下。简而言之,它从低 CPU 密集型 Task.Delay 开始,然后向上移动到 spinwait。它通常精确到约 50μs (0.05 ms)。
Some years later but here is what I came up with. It alines itself and is usually accurate to under 1ms. In a nutshell, it starts with a low CPU intensive Task.Delay and moves up to a spinwait. it is usually accurate to about 50µs (0.05 ms).
为了精确测量时间,您需要使用 Stopwatch 类
MSDN
For exact time measuring you need to use the Stopwatch class
MSDN
根据记录,这个问题现在似乎已得到解决。
通过 OP 代码,我在 .NET Core 3.1 中得到了这个:
For the record, this seems to be fixed nowadays.
With OPs code, I get this in .NET Core 3.1:
桌面操作系统(例如Windows)不是实时操作系统。这意味着,您不能期望完全准确,也不能强制调度程序在您想要的精确毫秒内触发您的代码。特别是在不确定的 .NET 应用程序中......例如,任何时候 GC 可以开始收集时,JIT 编译可能会慢一点或快一点......
Desktop operating system (such as windows) are not real-time operating system. which means, you can't expect full accuracy and you can't force the scheduler to trigger your code in the exact millisecond you want. Specially in .NET application which is non-deterministic...for examply, any time the GC can start collecting, a JIT compilation might be a bit slower or a bit faster....
Timer 和 DateTime 的精度不足以满足您的目的。请尝试使用秒表。
请参阅以下文章了解更多详细信息:
https://learn.microsoft.com/en-us/archive/blogs/ericlippert/ precision-and-accuracy-of-datetime
Timer and DateTime do not have enough accuracy for your purpose. Try the Stopwatch instead.
Look at the following article for more details:
https://learn.microsoft.com/en-us/archive/blogs/ericlippert/precision-and-accuracy-of-datetime
不是计时器不准确,而是 DateTime.Now,其广告公差为 16 毫秒。
相反,我会使用 Environment.Ticks 属性来测量测试期间的 CPU 周期。
编辑:Environment.Ticks 也基于系统计时器,可能与 DateTime.Now 具有相同的准确性问题。我建议选择
StopWatch
而不是,正如许多其他回答者提到的那样。Its not the timer that is inaccurate, but DateTime.Now, which has an advertised tolerance of 16ms.
Instead I would use the Environment.Ticks property to measure the CPU cycles during this test.
Edit: Environment.Ticks is also based off the system timer and may have the same accuracy issues as DateTime.Now. I'd advise choosing the
StopWatch
instead as many other answerers have mentioned.这并不能真正使计时器更加准确(如 它不能确保回调之间的时间恰好是 1 秒),但如果您需要的只是一个每秒触发一次的计时器,并且由于
~14ms
漂移问题,不会跳过几秒(如 OP 第 17 秒和第 19 秒之间的示例输出所示),您可以简单地将计时器更改为在下一秒开始时触发,如下所示一旦回调火灾(显然,如果您关心的只是确保间隔不会漂移,您可以对即将到来的分钟、即将到来的小时等执行相同的操作):This doesn't really make the timer more accurate (as in it doesn't make sure the time between callbacks is exactly 1 second), but if all you need is a timer which fires once every second and doesn't skip seconds because of the
~14ms
drifting issue (as demonstrated in OP's sample output between the 17th and 19th second), you could simply change the timer to fire at the start of the upcoming second as soon as the callback fires (and obviously you could do the same for upcoming minute, upcoming hour and so on, if all you care about is making sure the interval doesn't drift):这是另一种方法。在我的机器上精确到 5-20ms 以内。
Here is another approach. Accurate to within 5-20ms on my machine.
我为此开设了一个课程,看起来效果很好。没有任何不准确之处:
但这可能不是最好的解决方案。
I've made a class for that, and it seems to be working just fine. No inaccuracy whatsoever:
It might not be the best solution, though.