Was sind die besten Möglichkeiten, um Aufgaben in Echtzeit auf einem Nicht-Echtzeit-Betriebssystem/Kernel auszuführen?

Der sched_setscheduler(2) und seine Freunde erlauben Ihnen, zwei verschiedene weiche Echtzeit-Scheduler zu verwenden, SCHED_FIFO SCHED_RR. Prozesse, die unter diesen Planern ausgeführt werden, werden höher priorisiert als reguläre Prozesse. Solange Sie also nur ein paar dieser Prozesse haben und die Prioritäten zwischen ihnen kontrollieren, können Sie tatsächlich recht anständige Echtzeit-Antworten erhalten.

Wie in einem Kommentar angefordert, ist hier der Unterschied zwischen SCHED_FIFO und SCHED_RR:

Bei den "Echtzeit"-Schedulern gibt es bis zu 100 verschiedene Prioritäten (POSIX benötigt nur 32 verschiedene Ebenen, also sollte man sched_get_priority_min(2) und sched_get_priority_max(2) verwenden, um die tatsächliche Anzahl zu erhalten. Die Planer arbeiten beide, indem sie Prozesse vorbelegen und Threads mit niedrigerer Priorität, der Unterschied besteht darin, wie sie Aufgaben mit derselben Priorität behandeln.

SCHED_FIFO ist ein First-In-First-Out-Scheduler (daher der Name). Dies bedeutet, dass die Aufgabe, die zuerst in die Ausführungswarteschlange gelangt, ausgeführt werden darf, bis sie erledigt ist, freiwillig ihren Platz in der Ausführungswarteschlange aufgibt oder von einer Aufgabe mit höherer Priorität vorgezogen wird.

SCHED_RR ist ein Round-Robin-Scheduler. Das bedeutet, dass Tasks mit gleicher Priorität nur für ein bestimmtes Zeitquantum laufen dürfen. Wenn die Aufgabe noch ausgeführt wird, wenn dieses Zeitquantum abgelaufen ist, wird die Aufgabe vorzeitig beendet, und die nächste Aufgabe in der Ausführungswarteschlange (mit derselben Priorität) darf bis zu ihrem Zeitquantum ausgeführt werden. Wie bei SCHED_FIFO verdrängen Aufgaben mit höherer Priorität Aufgaben mit niedrigerer Priorität, wenn jedoch eine Aufgabe, die von einer Aufgabe mit höherer Priorität verdrängt wurde, erneut ausgeführt werden darf, dann darf sie nur für die verbleibende Zeit in ihrem Quantum ausgeführt werden. Sehen Sie sich den Noes-Abschnitt in sched_rr_get_interval(2) an, um zu erfahren, wie man das Zeitquantum für eine Aufgabe einstellt.

MRG

Sub-Millisekunden werden auf einem Nicht-RT-Kernel schwer zu garantieren sein. Ich weiß, dass in den letzten Jahren viel sehr gute Arbeit geleistet wurde (z. B. die große Kernel-Sperre ist weg), aber das ist immer noch nicht genug, um dies zu garantieren.

Sie könnten einen Blick auf Scientific Linux von diesen freundlichen Atomstörern bei CERN und Fermilab werfen. Auf diesem kann MRG installiert sein (siehe meinen Link), wodurch Sie eine vorkonfigurierte Einrichtung des PREEMPT_RT-Patches erhalten.

Oder wenn Sie das Geld haben, könnten Sie Redhat MRG bekommen. Das ist eine vollständig unterstützte Linux-Distribution mit integriertem PREEMPT-RT-Patch, sodass das problemanfällige Patchen des Kernels entfallen würde.

Die Sache ist die, Redhat verlangt viel dafür ($3000 PRO JAHR PRO INSTALLATION). Ich denke, sie haben herausgefunden, dass einer der größten Kunden dafür die Hochgeschwindigkeits-Trading-Investoren sind, die immer noch jede Menge Dollar haben und daher nicht bemerken werden, dass 3000 Dollar/Karton/Jahr aus der Tür gehen.

Wie ich mit MRG zurechtkam

Ich habe ziemlich viel mit MRG gearbeitet (mit beiden oben genannten), und es ist ziemlich gut. Es ersetzt die Interrupt-Service-Routinen im Stock-Kernel durch Threads, um den Interrupt zu bedienen. Das bedeutet, dass Sie Ihre Software mit höheren Prioritäten als den IRQ-Threads ausführen können! So etwas müssen Sie tun, wenn Sie sich der Garantie nähern wollen Latenz von weniger als einer Millisekunde bei Ihrer Anwendung.

Es scheint ein allmähliches Abdriften von MRG-Sachen in den Mainline-Kernel zu geben, was meiner Meinung nach eine gute Sache ist. Vielleicht wird es eines Tages zum Mainline-Ding.

Andere Fallstricke

Modernes CPU-Wärmemanagement kann eine echte Nervensäge sein. Ich hatte Systeme, die für 0,3 Sekunden abstürzten, während ein System Management Interrupt bedient wurde (vom blutenden BIOS, nicht vom Betriebssystem), nur weil sich die CPU ein wenig aufgewärmt hat. Sieh dir das an. Sie müssen also vorsichtig sein, was Ihre zugrunde liegende Hardware tut. Im Allgemeinen müssen Sie sich Sorgen machen, die verwaltete Kühlung moderner PCs aufzugeben und zu einem großen Lüfter zurückzukehren, der sich die ganze Zeit schnell dreht.

Sie können mit Linux ziemlich weit kommen, indem Sie die 'Störung' von anderen Prozessen auf den Echtzeitprozess entfernen. Ich habe mit dem gleichen Ding in Windows gespielt, was ein viel größerer Horror ist, um es richtig zu machen, aber es zeigt die Richtung. Also eine Art Checkliste:

• Das Wichtigste (seltsam aber wahr):die Hardware. Entscheiden Sie sich nicht für einen Laptop, dieser wird optimiert, um während SMM-Unterbrechungen seltsame Dinge zu tun. Du kannst nichts tun.
• Die Treiber:Linux (und Windows) hat schlechte Treiber und gute Treiber. Bezogen auf die Hardware. Und es gibt nur einen Weg, das herauszufinden:Benchmarking.

Vom Rest des Systems isolieren, alle Freigaben deaktivieren:

• Isolieren Sie eine CPU (man cpuset ). Erstellen Sie zwei CPU-Sätze, einen für normale Prozesse und einen für Ihren Echtzeitprozess.
• Reduzieren Sie den Echtzeitteil Ihres Codes auf das Minimum. Kommunizieren Sie mit großem Puffer mit anderen Teilen des Systems. Reduzieren Sie IO auf das absolute Minimum (da IO schlechte Garantien hat).
• Lassen Sie den Prozess die höchste (weiche) Echtzeitpriorität haben.
• HyperThreading deaktivieren (Sie möchten nicht teilen)
• weisen Sie den benötigten Speicher vorab zu und mlock() den Speicher.
• Isolieren Sie die von Ihnen verwendeten Geräte. Beginnen Sie, indem Sie dem Gerät einen dedizierten IRQ zuweisen (verschieben Sie die anderen Geräte auf einen anderen IRQ oder entfernen Sie andere Geräte/Treiber).
• Isolieren Sie das verwendete IO.

Aktivität des restlichen Systems reduzieren:

• Starten Sie nur Prozesse, die Sie wirklich wirklich brauchen.
• Entfernen Sie Hardware, die Sie nicht benötigen, wie Festplatten und andere Hardware.
• Swapping deaktivieren.
• Verwenden Sie keine Linux-Kernel-Module oder laden Sie sie im Voraus. Die Initialisierung von Modulen ist unvorhersehbar.
• entferne vorzugsweise auch den Benutzer :)

Machen Sie es stabil und reproduzierbar:

• Deaktivieren Sie alle Energieeinsparungen. Sie wollen immer die gleiche Leistung.
• Überprüfen Sie alle BIOS-Einstellungen und entfernen Sie alle 'Eventing' und 'Sharing' von ihnen. Also keine ausgefallenen Speedsteps, Wärmemanagement usw. Wählen Sie eine niedrige Latenzzeit, wählen Sie keine Dinge mit „Burst“ im Namen, da dies im Allgemeinen den Durchsatz gegen eine schlechtere Leistung eintauscht.
• Überprüfen Sie die Linux-Treibereinstellungen und senken Sie die Latenzen (falls zutreffend).
• benutze einen neueren Kernel, der versucht, jeden Tag etwas mehr wie ein Echtzeit-Kernel auszusehen.

Und dann ein Benchmarking durchführen, Stresstests durchführen und die Maschine tagelang eingeschaltet lassen, während die maximale Leistung aufgezeichnet wird. Latenzen.

Also:viel Glück :)