与 Windows 相比，Linux-ARM 上基于秒表滴答声的延迟不一致

Question

我正在开发一个项目，在该项目中，我使用秒表在 .NET 中进行基于滴答的精确延迟。该应用程序在 Windows 上运行完美，但当我在 Linux-ARM 平台（例如 Orange Pi）上运行它时，时间似乎不一致。

问题： 函数 DelayTicks(longticks) 用于创建精确的延迟：

private void DelayTicks(long ticks)  
{  
    var start = Stopwatch.GetTimestamp();  
    while (Stopwatch.GetTimestamp() - start < ticks)  
    {  
        // Busy wait  
    }  
}  

在 Windows 上，延迟按预期准确。然而，在 Linux-ARM 上，延迟要么比应有的更长或更短，导致时序关键型应用程序出现问题，例如发送 Art-Net 数据。

环境： Windows：准确的行为 Linux-ARM：时序不一致 .NET 版本：[指定版本，例如 .NET 7] 设备：橙派

我尝试过的： 已验证 Stopwatch.IsHighResolution — 在两个平台上都是如此。 使用 Stopwatch.Frequency 调整了滴答持续时间计算。 尝试使用 Task.Delay 或 Thread.Sleep 进行延迟，但它们无法提供应用程序所需的精度。

问题： Linux-ARM 平台上的秒表或高分辨率计时器是否存在任何已知问题？ 是否有更好的替代方案可以在 Linux-ARM 上实现精确的延迟？ 这是否与 Linux 内核处理高分辨率计时器的方式有关？

任何指导或替代方法将不胜感激！

Answer 1

据我所知，“Stopwatch”取决于硬件，而“Stopwatch.IsHighResolution”也取决于系统。

Task.Delay

或

Thread.Sleep

不仅不够精确而且不一致，因此也不应该使用。

我个人非常喜欢使用： 高精度时间戳

您的代码应如下所示：

using HighPrecisionTimeStamps;

private void DelayTicks(long ticks)
{
    // Get the initial timestamp
    var start = HighPrecisionTimeStampProvider.GetTimestamp();

    // Calculate the target timestamp
    var target = start + ticks;

   while (HighPrecisionTimeStampProvider.GetTimestamp() < target)
    {
        //busy wait
    }
}

如果有任何不清楚或您需要其他帮助，请告诉我:)