Stoppuhr-Ticks-basierte Verzögerung unter Linux-ARM im Vergleich zu Windows inkonsistent ⇐ Linux

[Guest]

Ich arbeite an einem Projekt, bei dem ich eine Stoppuhr für tickbasierte, präzise Verzögerungen in .NET verwende. Die Anwendung funktioniert einwandfrei unter Windows, aber wenn ich sie auf einer Linux-ARM-Plattform (z. B. Orange Pi) ausführe, scheint das Timing inkonsistent zu sein.
Problem:
Die Funktion DelayTicks (lange Ticks) wird verwendet, um präzise Verzögerungen zu erstellen:

Code: Select all

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

Unter Windows sind die Verzögerungen wie erwartet genau. Unter Linux-ARM ist die Verzögerung jedoch entweder länger oder kürzer als sie sein sollte, was zu Problemen in der zeitkritischen Anwendung führt, beispielsweise beim Senden von Art-Net-Daten.
Umgebung:
Windows: Genaues Verhalten
Linux-ARM: Inkonsistentes Timing
.NET-Version: [Geben Sie die Version an, z. B. .NET 7]
Gerät: Orange PiWas ich versucht habe:
Verifiziertes Stopwatch.IsHighResolution – es gilt auf beiden Plattformen.
Berechnung der Tickdauer mithilfe von Stopwatch.Frequency angepasst.
Versuch, Task zu verwenden. Delay oder Thread.Sleep für Verzögerungen, aber sie bieten nicht die für die Anwendung erforderliche Präzision.
Fragen:
Gibt es ein bekanntes Problem mit Stopwatch oder hochauflösende Timer auf Linux-ARM-Plattformen?
Gibt es bessere Alternativen, um präzise Verzögerungen auf Linux-ARM zu erreichen?
Könnte dies damit zusammenhängen, wie der Linux-Kernel mit hochauflösenden Timern umgeht?
Jede Anleitung oder alternative Vorgehensweise wäre sehr dankbar!