INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

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



Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!

09.10.2018, 19:02
Beitrag #1

RoK Offline
LVF-Neueinsteiger


Beiträge: 7
Registriert seit: Jul 2018

2018
2017
DE_EN

10178
Deutschland
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
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
09.10.2018, 20:40 (Dieser Beitrag wurde zuletzt bearbeitet: 09.10.2018 20:40 von GerdW.)
Beitrag #2

GerdW Offline
______________
LVF-Team

Beiträge: 15.687
Registriert seit: May 2009

09SP1, 11SP1, 17 (18)
1995
DE_EN

10×××
Deutschland
RE: startup.rtexe auf cRIO-904x mit "RT" Priorität ausführen
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!

Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
10.10.2018, 12:45
Beitrag #3

RoK Offline
LVF-Neueinsteiger


Beiträge: 7
Registriert seit: Jul 2018

2018
2017
DE_EN

10178
Deutschland
RE: startup.rtexe auf cRIO-904x mit "RT" Priorität ausführen
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
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
17.10.2018, 09:40 (Dieser Beitrag wurde zuletzt bearbeitet: 17.10.2018 09:41 von rolfk.)
Beitrag #4

rolfk Offline
LVF-Guru
*****


Beiträge: 2.278
Registriert seit: Jun 2007

alle seit 6.0
1992
EN

2901GG
Niederlande
RE: startup.rtexe auf cRIO-904x mit "RT" Priorität ausführen
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.

Rolf Kalbermatter
Test & Measurements Solutions
http://www.tm-solutions.eu
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
26.10.2018, 15:46
Beitrag #5

RoK Offline
LVF-Neueinsteiger


Beiträge: 7
Registriert seit: Jul 2018

2018
2017
DE_EN

10178
Deutschland
RE: startup.rtexe auf cRIO-904x mit "RT" Priorität ausführen
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
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
22.11.2018, 14:34 (Dieser Beitrag wurde zuletzt bearbeitet: 22.11.2018 14:37 von rolfk.)
Beitrag #6

rolfk Offline
LVF-Guru
*****


Beiträge: 2.278
Registriert seit: Jun 2007

alle seit 6.0
1992
EN

2901GG
Niederlande
RE: startup.rtexe auf cRIO-904x mit "RT" Priorität ausführen
(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.

Rolf Kalbermatter
Test & Measurements Solutions
http://www.tm-solutions.eu
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
Antwort schreiben 


Gehe zu: