gpt4 book ai didi

c# - 结合 Stopwatch 和 Timer 以通过平滑强制获得长期准确的事件

转载 作者:太空宇宙 更新时间:2023-11-03 10:22:13 27 4
gpt4 key购买 nike

首先,让我说一下,我知道 Windows 不是实时操作系统。我不希望任何给定的定时器间隔精确到 15 毫秒。然而,对我来说重要的是我的计时器滴答总和从长远来看是准确的,这对于股票计时器或秒表来说是不可能的。

如果将普通的 System.Timers.Timer(或者,更糟糕的是,Windows.Forms.Timer)配置为每 100 毫秒运行一次,它会在 100 毫秒到大约 115 毫秒之间的某个时间滴答作响。这意味着如果我需要做一天的事件,10 * 60 * 60 * 24 = 864,000 次,我可能会迟到三个多小时!这对我的申请来说是 Not Acceptable 。

我怎样才能最好地构建一个平均持续时间准确的计时器?我已经构建了一个,但我认为它可以更流畅、更有效,或者……必须有更好的方法。为什么 .NET 会提供低精度 DateTime.Now、低精度 Timer 和高精度 Diagnostics.Stopwatch,但没有高精度计时器?

我写了下面的定时器更新例程:

var CorrectiveStopwatch = new System.Diagnostics.Stopwatch();
var CorrectedTimer = new System.Timers.Timer()
{
Interval = targetInterval,
AutoReset = true,
};
CorrectedTimer.Elapsed += (o, e) =>
{
var actualMilliseconds = ;

// Adjust the next tick so that it's accurate
// EG: Stopwatch says we're at 2015 ms, we should be at 2000 ms
// 2000 + 100 - 2015 = 85 and should trigger at the right time
var newInterval = StopwatchCorrectedElapsedMilliseconds +
targetInterval -
CorrectiveStopwatch.ElapsedMilliseconds;

// If we're over 1 target interval too slow, trigger ASAP!
if (newInterval <= 0)
{
newInterval = 1;
}

CorrectedTimer.Interval = newInterval;

StopwatchCorrectedElapsedMilliseconds += targetInterval;
};

如您所见,它不太可能非常顺利。而且,在测试中,它一点也不流畅!我在一个示例运行中得到以下值:

100
87
91
103
88
94
102
93
103
88

此序列的平均值为 我了解网络时间和其他工具会平滑地强制当前时间以获得准确的计时器。也许执行某种 PID 循环以使目标间隔达到 targetInterval - 15/2 左右可能需要更小的更新,或者平滑可能会减少短事件和长事件之间的时间差异。我如何将其与我的方法相结合?是否有现有的图书馆可以做到这一点?

我将它与普通秒表进行了比较,它似乎是准确的。 5 分钟后,我测量了以下毫秒计数器值:

DateTime elapsed:  300119
Stopwatch elapsed: 300131
Timer sum: 274800
Corrected sum: 300200

30 分钟后,我测量了:

DateTime elapsed:  1800208.2664
Stopwatch elapsed: 1800217
Timer sum: 1648500
Corrected sum: 1800300

股票计时器比秒表慢 151.8 秒,占总数的 8.4%。这似乎非常接近 100 到 115 毫秒之间的平均滴答持续时间!此外,校正后的总和仍在测量值的 100 毫秒以内(这些比我用 watch 发现的误差更准确),所以这是可行的。

我的完整测试程序如下。它在 Windows 窗体中运行,需要“Form1”上的文本框,或者删除 textBox1.Text = 行并在命令行项目中运行它。

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows.Forms;

namespace StopwatchTimerTest
{
public partial class Form1 : Form
{
private System.Diagnostics.Stopwatch ElapsedTimeStopwatch;
private double TimerSumElapsedMilliseconds;
private double StopwatchCorrectedElapsedMilliseconds;
private DateTime StartTime;

public Form1()
{
InitializeComponent();
Run();
}

private void Run()
{
var targetInterval = 100;
// A stopwatch running in normal mode provides the correct elapsed time to the best abilities of the system
// (save, for example, a network time server or GPS peripheral)
ElapsedTimeStopwatch = new System.Diagnostics.Stopwatch();

// A normal System.Timers.Timer ticks somewhere between 100 ms and 115ms, quickly becoming inaccurate.
var NormalTimer = new System.Timers.Timer()
{
Interval = targetInterval,
AutoReset = true,
};
NormalTimer.Elapsed += (o, e) =>
{
TimerSumElapsedMilliseconds += NormalTimer.Interval;
};

// This is my "quick and dirty" corrective stopwatch
var CorrectiveStopwatch = new System.Diagnostics.Stopwatch();
var CorrectedTimer = new System.Timers.Timer()
{
Interval = targetInterval,
AutoReset = true,
};
CorrectedTimer.Elapsed += (o, e) =>
{
var actualMilliseconds = CorrectiveStopwatch.ElapsedMilliseconds; // Drop this into a variable to avoid confusion in the debugger

// Adjust the next tick so that it's accurate
// EG: Stopwatch says we're at 2015 ms, we should be at 2000 ms, 2000 + 100 - 2015 = 85 and should trigger at the right time
var newInterval = StopwatchCorrectedElapsedMilliseconds + targetInterval - actualMilliseconds;

if (newInterval <= 0)
{
newInterval = 1; // Basically trigger instantly in an attempt to catch up; could be smoother...
}
CorrectedTimer.Interval = newInterval;

// Note: could be more accurate with actual interval, but actual app uses sum of tick events for many things
StopwatchCorrectedElapsedMilliseconds += targetInterval;
};

var updateTimer = new System.Windows.Forms.Timer()
{
Interval = 1000,
Enabled = true,
};
updateTimer.Tick += (o, e) =>
{
var result = "DateTime elapsed: " + (DateTime.Now - StartTime).TotalMilliseconds.ToString() + Environment.NewLine +
"Stopwatch elapsed: " + ElapsedTimeStopwatch.ElapsedMilliseconds.ToString() + Environment.NewLine +
"Timer sum: " + TimerSumElapsedMilliseconds.ToString() + Environment.NewLine +
"Corrected sum: " + StopwatchCorrectedElapsedMilliseconds.ToString();
Console.WriteLine(result + Environment.NewLine);
textBox1.Text = result;
};

// Start everything simultaneously
StartTime = DateTime.Now;
ElapsedTimeStopwatch.Start();
updateTimer.Start();
NormalTimer.Start();
CorrectedTimer.Start();
CorrectiveStopwatch.Start();
}
}
}

最佳答案

Windows is not a real-time OS

更准确地说,在保护模式请求分页虚拟内存操作系统的第 3 环中运行的代码不能假定它可以提供任何执行保证。像页面错误这样简单的事情会大大延迟代码执行。更像是这样,第 2 代垃圾收集总是会破坏您的期望。 Ring 0 代码(驱动程序)通常具有出色的中断响应时间,模数一个在其基准测试中作弊的蹩脚视频驱动程序。

所以不,希望由 Timer 激活的代码将立即运行通常是空想。总会有延迟。 DispatcherTimer 或 Winforms 计时器只能在 UI 线程空闲时计时,异步计时器需要与所有其他线程池请求以及竞争处理器的其他进程拥有的线程竞争。

因此,您永远不想做的一件事是在事件处理程序或回调中增加耗时计数器。它会很快偏离流逝的挂钟时间。以一种完全不可预测的方式,机器负载越重,它就越落后。

解决方法很简单,如果您关心实际耗时,则使用时钟。无论是 DateTime.UtcNow 还是 Environment.TickCount,两者之间没有根本区别。启动计时器时将值存储在变量中,在事件或回调中减去它以了解实际耗时。它在很长一段时间内都非常精确,精度受时钟更新速率的限制。默认情况下是每秒 64 次(15.6 毫秒),它可以通过调用 timeBeginPeriod() 来提升。 .保守地这样做,这对功耗不利。

秒表具有相反的特性,它高度准确但不精确。它未校准为像 DateTime.UtcNow 和 Environment.TickCount 这样的原子钟。并且对于生成事件完全没有用,在循环中燃烧核心以检测耗时将使您的线程在它的量子燃烧后被放入狗屋一段时间。仅将其用于临时分析。

关于c# - 结合 Stopwatch 和 Timer 以通过平滑强制获得长期准确的事件,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/33000567/

27 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com