LabVIEWForum.de - CPU Last steigt langsam -> Konzeptfehler?

LabVIEWForum.de

Normale Version: CPU Last steigt langsam -> Konzeptfehler?
Du siehst gerade eine vereinfachte Darstellung unserer Inhalte. Normale Ansicht mit richtiger Formatierung.
Seiten: 1 2
Hy,
ich habe auf meinem Desktop RT 3 zeitgesteuerte Schleifen.
Jeder Schleife ist eine "Aufgabe" sowie einem CPU Kern zugeordnet.

Auf dem FPGA werden die Signale von 32 Sensoren erfasst.
Ist von einem Sensor eine gewisse Anzahl an Messwerten erfasst so werden diese als "Paket" mit einem Erkennungsmerkmal in einen DMA FIFO geschrieben.
Anhand des Erkennungsmerkmals werden die gelesenen Daten aus dem DMA FIFO auf dem RT System gelesen, zugeordnet und verarbeitet.

Konzept auf dem RT System ist folgendes:
1te Schleife: Liest Daten von einem FPGA DMA FIFO und schreibt sie in einen RT FIFO.
2te Schleife: RT FIFO lesen,die Messwerte dem richtigen Sensor zuordnen und in ein Array schreiben.

Noch umzusetzen ist:
3te Schleife: Die Werte im Array lesen und gemäß dem Sensorprotokoll umrechnen, formatieren und in einer Datei speichern.

Probleme gibt es mit Schleife 2, die CPU Auslastung vom Kern 2 steigt langsam an, bis irgendwann 100% erreicht werden.
Die Ursache ist mir noch unklar, da die Schleife 2 ja nichts anderes macht als Werte in das dazugehörige Array zu schreiben.

Nun die Frage was verursacht diesen Anstieg der CPU Last und wie kann Abhilfe geschaffen werden?

Gruß,
Ben Blush
Welche Einstellungen hast du beim RT-FIFO gewählt? Polling beim Lesen, wenn der RT-FIFO eigentlich leer ist, treibt die CPU-Last auf 100%.

Gruß, Jens
Hallo Ben,

Zitat:Die Ursache ist mir noch unklar, da die Schleife 2 ja nichts anderes macht als Werte in das dazugehörige Array zu schreiben.
Du arbeitest hier aber nicht mit BuildArray (oder gar InsertIntoArray)?
Du nutzt schon ein Array fester Länge und ReplaceArraySubset? Oder einen RT-FIFO, falls er ins Konzept passt?
Es ist beim Lesen sowie beim Schreiben Polling gewählt.

Ich lasse mir die Anzahl der vorhanden Elemente im RT FIFO permanent anzeigen,
leer wird er nie.

Ich habe jetzt zum Testen beim Lesen auf Blocking gestellt und das ganze für 10min laufen lassen.
Eine Veränderung lässt sich an der CPU Auslastung nicht feststellen.

Sie steigt immer noch permanent, nach 10min bei 23% Auslastung.
23% finde ich noch nicht schlimm, zumindest wenn sich die CPU-Last irgendwann einpendelt.

Aber die Rückfrage von Gerd ist berechtigt: "In ein Array schreiben", was machst du da genau? Allozierst du an dieser Stelle dynamisch Speicher? Das wäre durchaus ein Grund für steigende CPU-Last.
EDIT: Hierzu zusätzlich Speicherverbrauch und "größten zusammenhängenden Speicherblock" überwachen.

Ansonsten, zu wenig Infos, da müsstest du mal dein VI posten.

Gruß, Jens
Hy,
Aktuell nutzte ich die Funktion "In Array einfügen" da ich mit dem Programm tagelang die Sensorsignale aufzeichnen und auswerten möchte.
Daher kann ich keine Aussage treffen wie groß das Endarray sein soll.

Nächste Punkt ist das die Auslastung der CPU bei einem Sensor diese Werte erreicht, vermute stark das mit 32 Sensoren das so wie es jetzt programmiert ist nicht funktionieren wird.

VI sieht noch etwas chaotisch aus Wink
Hallo Ben,

Zitat:Aktuell nutzte ich die Funktion "In Array einfügen" da ich mit dem Programm tagelang die Sensorsignale aufzeichnen und auswerten möchte.
Wie befürchtet - und eben falsch…

Schau bitte in die LabVIEW-Hilfe, da gibt es ein eigenes Kapitel zum Umgang mit großen Datenmengen! Und das trifft auf ein (ggü. einem PC) deutlich eingeschränktes RT-Target noch mehr zu!

- Bitte immer mit Arrays fester Länge arbeiten. ReplaceArraySubset nutzen!
- "Tagelange Messung" heißt nicht automatisch, dass man diese Messdaten auch alle im Speicher halten muss…

Kannst du das VI nochmal in LV2011 speichern?
Bitteschön Smile
Hallo Ben,

- Du definierst deinen RT-FIFO mit "9000 Elemente pro Array", liest aber aus dem FPGA-FIFO nur Datenblöcke knapp über 900 Elemente. Warum diese Verschwendung an Speicher? Hilfe zur Funktion lesen!
- Ersetze die Arrays variabler Größe durch Arrays fester Größe in deiner unteren Schleife. Es gibt keinen Grund, Daten von "mehreren Tagen" im Speicher zu halten…
Hy,
ich werde die Änderungen umsetzten.

Melde mich dann mit den Ergebnissen.

Vielen Dank schonmal.
Seiten: 1 2
Referenz-URLs