.NET中最准确的计时器

本文关键字:计时器 NET | 更新日期: 2023-09-27 18:24:06

运行以下(稍微伪的)代码会产生以下结果。我对计时器的不精确性感到震惊(每个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

.NET中最准确的计时器

我也有一个精确到1ms的类。我从论坛上获取了Hans Passant的代码
https://social.msdn.microsoft.com/Forums/en-US/6cd5d9e3-e01a-49c4-9976-6c6a2f16ad57/1-millisecond-timer
并将其封装在一个类中,以便在表单中使用。如果需要,可以轻松设置多个计时器。在下面的示例代码中,我使用了2个定时器。我已经测试过了,它工作正常。

// AccurateTimer.cs
using System;
using System.Windows.Forms;
using System.Runtime.InteropServices;
namespace YourProjectsNamespace
{
    class AccurateTimer
    {
        private delegate void TimerEventDel(int id, int msg, IntPtr user, int dw1, int dw2);
        private const int TIME_PERIODIC = 1;
        private const int EVENT_TYPE = TIME_PERIODIC;// + 0x100;  // TIME_KILL_SYNCHRONOUS causes a hang ?!
        [DllImport("winmm.dll")]
        private static extern int timeBeginPeriod(int msec);
        [DllImport("winmm.dll")]
        private static extern int timeEndPeriod(int msec);
        [DllImport("winmm.dll")]
        private static extern int timeSetEvent(int delay, int resolution, TimerEventDel handler, IntPtr user, int eventType);
        [DllImport("winmm.dll")]
        private static extern int timeKillEvent(int id);
        Action mAction;
        Form mForm;
        private int mTimerId;
        private TimerEventDel mHandler;  // NOTE: declare at class scope so garbage collector doesn't release it!!!
        public AccurateTimer(Form form,Action action,int delay)
        {
            mAction = action;
            mForm = form;
            timeBeginPeriod(1);
            mHandler = new TimerEventDel(TimerCallback);
            mTimerId = timeSetEvent(delay, 0, mHandler, IntPtr.Zero, EVENT_TYPE);
        }
        public void Stop()
        {
            int err = timeKillEvent(mTimerId);
            timeEndPeriod(1);
            System.Threading.Thread.Sleep(100);// Ensure callbacks are drained
        }
        private void TimerCallback(int id, int msg, IntPtr user, int dw1, int dw2)
        {
            if (mTimerId != 0)
                mForm.BeginInvoke(mAction);
        }
    }
}
// FormMain.cs
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
namespace YourProjectsNamespace
{
    public partial class FormMain : Form
    {
        AccurateTimer mTimer1,mTimer2;
        public FormMain()
        {
            InitializeComponent();
        }
        private void FormMain_Load(object sender, EventArgs e)
        {
            int delay = 10;   // In milliseconds. 10 = 1/100th second.
            mTimer1 = new AccurateTimer(this, new Action(TimerTick1),delay);
            delay = 100;      // 100 = 1/10th second.
            mTimer2 = new AccurateTimer(this, new Action(TimerTick2), delay);
        }
        private void FormMain_FormClosing(object sender, FormClosingEventArgs e)
        {
            mTimer1.Stop();
            mTimer2.Stop();
        }
        private void TimerTick1()
        {
            // Put your first timer code here!
        }
        private void TimerTick2()
        {
            // Put your second timer code here!
        }
    }
}

我认为其他答案未能解决为什么在OP代码的每次迭代中都有14ms的转换;这是而不是,因为系统时钟不精确(DateTime.Now也不精确,除非您关闭了NTP服务或设置了错误的时区或其他愚蠢的事情!这只是不精确)。

精确计时器

即使使用不精确的系统时钟(使用DateTime.Now,或者将太阳能电池连接到ADC上,以判断太阳在天空中的高度,或者在峰值潮汐之间划分时间,等等),遵循这种模式的代码也将具有平均为零的回转(它将非常准确,平均每一次刻度之间只有1秒):

var interval = new TimeSpan(0, 0, 1);
var nextTick = DateTime.Now + interval;
while (true)
{
    while ( DateTime.Now < nextTick )
    {
        Thread.Sleep( nextTick - DateTime.Now );
    }
    nextTick += interval; // Notice we're adding onto when the last tick  
                          // was supposed to be, not when it is now.
    // Insert tick() code here
}

(如果你正在复制和粘贴它,请注意你的勾号代码执行时间比interval长的情况。我将把它留给读者一个练习,让读者找到简单的方法,让它跳过nextTick未来落地所需的节拍。)

计时器不准确

我猜微软对System.Threading.Timer的实现遵循了这种模式。即使有一个非常精确的系统计时器,这种模式也总是会发生转换(因为即使只是执行添加操作也需要时间):

var interval = new TimeSpan(0, 0, 1);
var nextTick = DateTime.Now + interval;
while (true)
{
    while ( DateTime.Now < nextTick )
    {
        Thread.Sleep( nextTick - DateTime.Now );
    }
    nextTick = DateTime.Now + interval; // Notice we're adding onto .Now instead of when
                                        // the last tick was supposed to be. This is
                                        // where slew comes from.
    // Insert tick() code here
}

因此,对于那些可能有兴趣推出自己的计时器的人来说,不要遵循第二种模式。

精确的时间测量

正如其他海报所说,Stopwatch类在时间测量方面提供了很好的精度,但如果遵循错误的模式,则对的精度毫无帮助。但是,正如@Shahar所说,你一开始就不会有一个非常精确的计时器,所以如果你追求的是完美的精度,你需要重新思考。

免责声明

请注意,微软并没有太多地谈论System.Threading.Timer类的内部结构,所以我对它进行了有教育意义的猜测,但如果它像鸭子一样嘎嘎作响,那么它很可能就是鸭子。此外,我意识到这已经有好几年的历史了,但这仍然是一个相关的(我认为没有答案)问题。

编辑:更改了@Shahar回答的链接

编辑:微软有很多在线内容的源代码,包括System.Threading.Timer,供任何有兴趣了解微软如何实现这个小定时器的人使用。

要精确测量时间,您需要使用Stopwatch类MSDN

几年后,但以下是我的想法。它本身是线性的,通常精确到1ms以下。简而言之,它从一个低CPU密集型任务开始。延迟,然后向上移动到spinwait。它通常精确到大约50µs(0.05ms)。

static void Main()
{
    PrecisionRepeatActionOnIntervalAsync(SayHello(), TimeSpan.FromMilliseconds(1000)).Wait();
}
// Some Function
public static Action SayHello() => () => Console.WriteLine(DateTime.Now.ToString("ss.ffff"));
        
public static async Task PrecisionRepeatActionOnIntervalAsync(Action action, TimeSpan interval, CancellationToken? ct = null)
{
    long stage1Delay = 20 ;
    long stage2Delay = 5 * TimeSpan.TicksPerMillisecond;
    bool USE_SLEEP0 = false;
    DateTime target = DateTime.Now + new TimeSpan(0, 0, 0, 0, (int)stage1Delay + 2);
    bool warmup = true;
    while (true)
    {
        // Getting closer to 'target' - Lets do the less precise but least cpu intesive wait
        var timeLeft = target - DateTime.Now;
        if (timeLeft.TotalMilliseconds >= stage1Delay)
        {
            try
            {
                await Task.Delay((int)(timeLeft.TotalMilliseconds - stage1Delay), ct ?? CancellationToken.None);
            }
            catch (TaskCanceledException) when (ct != null)
            {
                return;
            }
        }
        // Getting closer to 'target' - Lets do the semi-precise but mild cpu intesive wait - Task.Yield()
        while (DateTime.Now < target - new TimeSpan(stage2Delay))
        {
            await Task.Yield();
        }
        // Getting closer to 'target' - Lets do the semi-precise but mild cpu intensive wait - Thread.Sleep(0)
        // Note: Thread.Sleep(0) is removed below because it is sometimes looked down on and also said not good to mix 'Thread.Sleep(0)' with Tasks.
        //       However, Thread.Sleep(0) does have a quicker and more reliable turn around time then Task.Yield() so to 
        //       make up for this a longer (and more expensive) Thread.SpinWait(1) would be needed.
        if (USE_SLEEP0)
        {
            while (DateTime.Now < target - new TimeSpan(stage2Delay / 8))
            {
                Thread.Sleep(0);
            }
        }
        // Extreamlly close to 'target' - Lets do the most precise but very cpu/battery intesive 
        while (DateTime.Now < target)
        {
            Thread.SpinWait(64);
        }
        if (!warmup)
        {
            await Task.Run(action); // or your code here
            target += interval;
        }
        else
        {
            long start1 = DateTime.Now.Ticks + ((long)interval.TotalMilliseconds * TimeSpan.TicksPerMillisecond);
            long alignVal = start1 - (start1 % ((long)interval.TotalMilliseconds * TimeSpan.TicksPerMillisecond));
            target = new DateTime(alignVal);
            warmup = false;
        }
    }
}

Sample output:
07.0000
08.0000
09.0000
10.0001
11.0000
12.0001
13.0000
14.0000
15.0000
16.0000
17.0000
18.0000
19.0001
20.0000
21.0000
22.0000
23.0000
24.0000
25.0000
26.0000
27.0000
28.0000
29.0000
30.0000
31.0000
32.0138 <---not that common but can happen
33.0000
34.0000
35.0001
36.0000
37.0000
38.0000
39.0000
40.0000
41.0000

记录在案,现在似乎已经解决了这个问题。

使用操作系统代码,我在.NET Core 3.1:中得到了这一点

41.4263
42.4263
43.4291
44.4262
45.4261
46.4261
47.4261
48.4261
49.4260
50.4260
51.4260
52.4261

桌面操作系统(如windows)是而不是实时操作系统。这意味着,你不能期望完全的准确性,也不能强迫调度器在你想要的毫秒内触发你的代码。特别是在.NET应用程序中,它是不确定的。。。例如,每当GC可以开始收集时,JIT编译可能会慢一点或快一点。。。。

Timer和DateTime的精度不足以满足您的要求。试试秒表。查看以下文章了解更多详细信息:

https://learn.microsoft.com/en-us/archive/blogs/ericlippert/precision-and-accuracy-of-datetime

不是计时器不准确,而是DateTime.现在,它的广告容差为16ms。

相反,我会使用Environment.Ticks属性来测量测试期间的CPU周期。

编辑:环境。Ticks也基于系统计时器,可能与DateTime.Now有相同的准确性问题。我建议选择StopWatch,就像许多其他回答者提到的那样。

这并不能真正使计时器更准确(就像在中一样,它不能确保回调之间的时间正好是1秒),但如果你只需要一个每秒触发一次并且不会因为~14ms漂移问题而跳过秒的计时器(如OP在第17秒和第19秒之间的样本输出所示),你可以简单地将计时器更改为在回调一启动就在下一秒开始时启动(很明显,你可以对下一分钟、下一小时等等做同样的事情,如果你只关心确保间隔不会漂移的话):

using System.Threading;
static Timer timer;
void Main()
{   
    // 1000 - DateTime.UtcNow.Millisecond = number of milliseconds until the next second
    timer = new Timer(TimerCallback, null, 1000 - DateTime.UtcNow.Millisecond, 0);
}
void TimerCallback(object state)
{   
    // Important to do this before you do anything else in the callback
    timer.Change(1000 - DateTime.UtcNow.Millisecond, 0);
    Debug.WriteLine(DateTime.UtcNow.ToString("ss.ffff"));
}
Sample Output:
...
25.0135
26.0111
27.0134
28.0131
29.0117
30.0135
31.0127
32.0104
33.0158
34.0113
35.0129
36.0117
37.0127
38.0101
39.0125
40.0108
41.0156
42.0110
43.0141
44.0100
45.0149
46.0110
47.0127
48.0109
49.0156
50.0096
51.0166
52.0009
53.0111
54.0126
55.0116
56.0128
57.0110
58.0129
59.0120
00.0106
01.0149
02.0107
03.0136

这里是另一种方法。在我的机器上精确到5-20ms以内。

public class Run
{
    public Timer timer;
    public Run()
    {
        var nextSecond = MilliUntilNextSecond();
        var timerTracker = new TimerTracker()
        {
            StartDate = DateTime.Now.AddMilliseconds(nextSecond),
            Interval = 1000,
            Number = 0
        };
        timer = new Timer(TimerCallback, timerTracker, nextSecond, -1);
    }
    public class TimerTracker
    {
        public DateTime StartDate;
        public int Interval;
        public int Number;
    }
    void TimerCallback(object state)
    {
        var timeTracker = (TimerTracker)state;
        timeTracker.Number += 1;
        var targetDate = timeTracker.StartDate.AddMilliseconds(timeTracker.Number * timeTracker.Interval);
        var milliDouble = Math.Max((targetDate - DateTime.Now).TotalMilliseconds, 0);
        var milliInt = Convert.ToInt32(milliDouble);
        timer.Change(milliInt, -1);
        Console.WriteLine(DateTime.Now.ToString("ss.fff"));
    }
    public static int MilliUntilNextSecond()
    {
        var time = DateTime.Now.TimeOfDay;
        var shortTime = new TimeSpan(0, time.Hours, time.Minutes, time.Seconds, 0);
        var oneSec = new TimeSpan(0, 0, 1);
        var milliDouble = (shortTime.Add(oneSec) - time).TotalMilliseconds;
        var milliInt = Convert.ToInt32(milliDouble);
        return milliInt;
    }
}

我已经为此创建了一个类,它似乎运行得很好。没有任何不准确性:

class AccurateTimer
{
    public event EventHandler<EventArgs> Tick;
    public bool Running { get; private set; }
    public int Interval { get; private set; }
    public AccurateTimer(int interval_ = 1000)
    {
        Running = false;
        Interval = interval_;
    }
    public void Start()
    {
        Running = true;
        Thread thread = new Thread(Run);
        thread.Start();
    }
    public void Stop()
    {
        Running = false;
    }
    private void Run()
    {
        DateTime nextTick = DateTime.Now.AddMilliseconds(Interval);
        while (Running)
        {
            if (DateTime.Now > nextTick)
            {
                nextTick = nextTick.AddMilliseconds(Interval);
                OnTick(EventArgs.Empty);
            }
        }
    }
    protected void OnTick(EventArgs e)
    {
        EventHandler<EventArgs> copy = Tick;
        if (copy != null)
        {
            copy(this, e);
        }
    }
}

不过,这可能不是最好的解决方案。