startup.rtexe auf cRIO-904x mit "RT" Priorität ausführen

Liebe LabVIEW-Entwickler,

bei dem Betrieb einer RT-Applikation auf einem cRIO-9041 (LinuxRT) hab ich folgendes, für mich unerwartetes Verhalten festgestellt: Wenn ich im Linux via Skript ein zyklisches Zippen von Messdateien starte wird der RT-Anwendung weniger CPU-Kapazität zugewiesen (gZIP-Thread bekommt mehr CPU-Kapazität). Dabei wird auch die Zykluszeit einer Whileschleife, in welcher einige Berechnungen in weniger als 1s durchgeführt werden sollen, unzulässig vergrößert.

Meine Erwartung wäre: Die Berechnungen sollen unter 1s abgeschlossen werden, also müsste sich der Thread der RT-Anwendung aufgrund seiner hohen Ausführungspriorität die notwenigen CPU-Berechnungszeiten "verschaffen" (Scheduler).
Tatsächlich habe ich aber festgestellt, dass der Prozess der RT-Applikation ({MainAppThread} ./lvrt liblvrt-ui.so) lediglich mit normaler Priorität vom Linux-System ausgeführt wird. Der PR-Wert ist 20, so wie auch 20 ist für den gZIP-Thread oder etwa einen Firefox-Prozess.

Nun meine Frage(n): Ist das Verhalten wie oben beschreiben so zu erwarten? Wie kann die Ausführungspriorität der RT-Applikation maximiert werden (auf PR-Wert "RT")? Was könnte noch getan werden, um den Einfluss weiterer Prozesse/Threads auf die Ausführungsperformance der RT-Applikation zu minimieren?


WEITERE INFOS:
Programmiermodus: Real-Time CPU (seit cRIO-Generation 904x)
Architektur RT-Applikation: Queued Message Handler
Berechnungsschleife wird asynchron parallel zu weiterem Programmcode ausgeführt
CPU-Last (nur RT-Applikation): unter 30% >>> Zykluszeit Berechnungsschleife: ca. 0,5s
CPU-Last (RT und gZIP): ca. 95 bis 100% >>> Zykluszeit Berechnungsschleife: über 1s
Firmware cRIO-9041: 5.6.0f0f
Betriebssystem: NI Linux Real-Time x64 4.9.47 -rt37-6.0.0f1


Vielen Dank und Gruß aus Berlin
RoK

Hallo RoK,

herzlich willkommen im Forum!

Zitat:Was könnte noch getan werden, um den Einfluss weiterer Prozesse/Threads auf die Ausführungsperformance der RT-Applikation zu minimieren?

Kannst du das ZIPpen der Messdaten nicht aus der RTExe heraus anstossen/durchführen? Dann hättest du selbst die Kontrolle über den Zeitpunkt dieser Rechenlast…

Auch Gruß aus Berlin!

Hallo GerdW,

vielen Dank für den Willkommengruß - obwohl hier schon viel unterwegs, war ich bisher ja noch nicht so aktiv.

Dein nachvollziehbarer Vorschlag würde sicherlich die Situation begünstigen. Allerdings ist das Problem von prinzipieller Natur. Wir verfolgen im Team das Prinzip die betriebssystemseitig durchführbaren Routinen, wie etwa Dateioperationen mittels Skripten zu automatisieren (Effizienz der Code-Erstellung & Wartbarkeit & Flexibilität, da nur wenige LabVIEW-Programmierer). Das sind neben dem ZIPpen noch weitere Dinge, welche in LabVIEW programmiert möglicherweise mehr Ressourcen beanspruchen würden.

Daher die Frage, ob in der "lvrt.conf" oder "ni-rt.ini" oder ggfs. auch woanders eine Prozesspriorisierung der LabVIEW-Applikation vorgenommen werden kann, sodass diese direkt mit PR=RT-Priorisierung ausgeführt wird?

LG RoK

Und was ist mit der umgekehrten Variante? Statt die Priorität der LabVIEW Applikation zu erhöhen und möglicherweise allerlei Dinge die in LabVIEW geschickt ausgebalanciert sind wie etwa die Prioritäteneinstellung von Timed Loops eventuel über den Haufen zu werfen, könntest Du im Script wo das gzippen (oder generell immer wenn eine potentiel längere Operation deren Laufzeit unkritisch ist) angestossen wird, den entsprechenden Task doch mit weniger hoher Priorität starten. Einen Task mit weniger hoher Priorität zu starten sollte immer möglich sein, ohne irgendwelche extra Rechte.

Oder wenn Du eine wirklich zeitkritische Aufgabe in Deiner LabVIEW Applikation hast kannst Du sie auch innerhalb einer Timed Loop ausführen. Die Timed Loop bietet Möglichkeiten um die Priorität einzustellen auch wenn diese nicht direkt mit der OS Priorïtät übereinstimmt, denn LabVIEW kann sich selber nicht plötzlich eine höhere Priorität zuweisen dann die mit der es gestartet wurde.

Hallo Rolf,

Zitat:... könntest Du ... den entsprechenden Task doch mit weniger hoher Priorität starten. ...

So werden wir das vermutlich letztlich machen (müssen) für kleinere externe Prozesse. Und das aufwändigere ZIPen pack ich dann jetzt doch ins LabVIEW - danke für die Anregung GerdW.

Zitat:...Statt die Priorität der LabVIEW Applikation zu erhöhen und möglicherweise allerlei Dinge die in LabVIEW geschickt ausgebalanciert sind wie etwa die Prioritäteneinstellung von Timed Loops eventuel über den Haufen zu werfen...

Agiert der Linux-Scheduler nicht unabhängig von der Timing- und Priorisierungs-Engine von NI im RT-Application-Thread? Damit meine ich: Warum sollte eine Höhere System-Priorität der RT-Applikation die "thread-interne" Priorisierung überhaupt beeinflussen? Ich habe das so verstanden, dass die Linux-seitige Priorisierung vereinfacht ausgedrückt Anteile an der verfügbaren CPU-Rechenzeit zur Verfügung stellt und von allem, was innerhalb eines Threads / Hier: RT-Application-Thread, keine Kenntnis hat.



Gruß und Danke für das Mitgrübeln!
RoK

(26.10.2018 15:46 )RoK schrieb:  Agiert der Linux-Scheduler nicht unabhängig von der Timing- und Priorisierungs-Engine von NI im RT-Application-Thread? Damit meine ich: Warum sollte eine Höhere System-Priorität der RT-Applikation die "thread-interne" Priorisierung überhaupt beeinflussen? Ich habe das so verstanden, dass die Linux-seitige Priorisierung vereinfacht ausgedrückt Anteile an der verfügbaren CPU-Rechenzeit zur Verfügung stellt und von allem, was innerhalb eines Threads / Hier: RT-Application-Thread, keine Kenntnis hat.

Das Ganze ist etwas komplizierter als Du denkst. Der Linux scheduler hat tatsächlich keinerlei spezifischen Kenntnisse was eine Applikation mit den Threads tut, die sie von ihm anfragt aber LabVIEW als Applikation started je nach Anzahl Cores die Dein System zur Verfügung stellt, default mit bis zu 8 threads per Subsystem per Core auf (aber das ist in guter LabVIEW Art mit Settings im ini File konfigurierbar und Du kannst auch explizit 100 Threads in einem Subsystem initialisieren lassen). Die Subsysteme sind die Threadgruppen die LabVIEW intern hält, wie Standard, Instrument IO, DAQ, Other1 und Other2 und dann noch den Hauptthread der auch als User Interface thread bezeichnet wird. In diesen Threads teilt LabVIEW die VIs ein wenn Du in den Execution Settings eine explizite Zuweisung vornimmst, anders werden die VIs im selben Subsystem ausgeführt wie deren Aufrufer und das Toplevel VI im Standard Subsystem, wenn keine spezifieke Zuweisung in den VI Settings besteht.

Durch eine höhere Priorität an die Applikation zuzuweisen bekommen alle diese potentiel 40 oder mehr Threads diese Priorität was auf die Systemperformance und die Kooperation mit anderen Teilen des Systems sehr weitgehende Auswirkungen haben kann.

Hallo Rolf,

vielen Dank für deine Erläuterungen.

Ich habe im Zuge dessen die Performance meiner Software dahingehend optimiert, dass ich

1. die Subsysteme konsequenter zugewiesen habe
2. einige VIs ablaufinvariant konfiguriert habe sowie
3. die Ausführungsreihenfolge durch konsequenteres durchdrahten der Error-Cluster festlege

Danke noch einmal und viele Grüße aus Berlin,
RoK