Sehr hohe CPU Auslastung bei hoher Datenerfassungsrate

Hallo zusammen,

Ich hatte vor kurzem schon einmal ein Thema erstellt bezüglich einer möglichst hohen Datenerfassungsrate.
Das klappt jetzt auch prima, allerdings nur, wenn das VI auf höchster Priorität läuft.
Dann kommt der Rechner aber auch an seine Grenzen und die CPU (Dual Core 2,4GHz) läuft auf 100%.

Meine Vermutung ist nun, dass es mit den While Schleifen in der Erzeugerschleife zusammenhängt, da diese ungebremst laufen.
Wenn sie allerdings bremse (wartezeit), stockt auch die Datenerfassung.

Ich benötige an der Stelle eine Verbesserung. Für Ideen bin ich sehr dankbar!

Viele Grüße
Steffen

Hallo Stefan,

Erzeuger:
- Warum muss man die Anzahl der Bytes im Buffer der seriellen Schnittstelle ungebremst abfragen?
- Warum muss man die serielle Schnittstelle einzelbyteweise auslesen? Warum nicht einfach mehrere Bytes mit einmal abfragen?
- Wozu die Anzahl der Bytes im Buffer abfragen, wenn man hinterher doch schon weiß, wieviele Bytes man lesen möchte? Einfach nur den TimeOut groß genug setzen!
- Warum der CoercionDot am Wait?
- 3Mbaud sind nicht gerade Standard…

Verbraucher1&2:
- Warum die Bytes einzeln auswerten? Warum nicht das U8-Array mittels Decimate in seine Bestandteile zerlegen und mit Arrays arbeiten?
- Warum hier wandeln nach DDT?
- Stop-Bedingung direkt mit dem Fehlerausgang des ReadQueue verbinden!

Allgemein:
2 Verbraucher, die auf eine einzige Queue schauen, geht gar nicht!

Dein Erzeuger dürfte für die CPU-Last verantwortlich sein, deine Verbraucher sind "nur suboptimal" programmiert…

Erzeuger:
- Warum muss man die Anzahl der Bytes im Buffer der seriellen Schnittstelle ungebremst abfragen?

Habe eine Bremse eingebaut, bringt keine Verbesserung oder Verschlechterung

- Warum muss man die serielle Schnittstelle einzelbyteweise auslesen? Warum nicht einfach mehrere Bytes mit einmal abfragen?

An dieser Stelle suche ich den Beginn des Datenpakets. Dabei sendet der µC einmal das Byte 0x80 (128). Anschließend kommen weiter 3960 Bytes, die die Daten enthalten. Das könnte man sicherlich optimieren, allerdings weis ich nicht so recht wie...


- Wozu die Anzahl der Bytes im Buffer abfragen, wenn man hinterher doch schon weiß, wieviele Bytes man lesen möchte? Einfach nur den TimeOut groß genug setzen!

Dabei will ich nur sichergehen, dass genügend Bytes im Buffer sind. Außerdem soll der Buffer nicht vollaufen. Wenn ich das richtig sehe, dann ist der Buffer schon nach 0,01452 Sekunden voll (3MBaud Rate, 11 Bit pro Symbol und 3640 Symbole)

- Warum der CoercionDot am Wait?
Offenbar kann man der Funktion keine bruchteile von Millisekunden übergeben. Hm irgendwie schlapp... Kennst du eine Alternative?

- 3Mbaud sind nicht gerade Standard…
Ja, aber schnell

Verbraucher1&2:
- Warum die Bytes einzeln auswerten? Warum nicht das U8-Array mittels Decimate in seine Bestandteile zerlegen und mit Arrays arbeiten?

Kannst du mir den deutschen Namen von "Decimate" nennen? Ich finde das Teil nicht in der Palette. Mit Arrays hab ich noch so meine Schwierigkeiten...

- Warum hier wandeln nach DDT?

An sich soll das Signal auf einem XY Graph angezeigt werden. Das 9. Byte enthält den Wert eines Weggebers, der allerdings aufaddiert werden muss. Hier habe ich noch eine Baustelle.

- Stop-Bedingung direkt mit dem Fehlerausgang des ReadQueue verbinden!
Okay.

Allgemein:
-2 Verbraucher, die auf eine einzige Queue schauen, geht gar nicht!

Hm, ich hätte gerne das Schreiben der Daten parallel zum Anzeigen. Da muss ich mal drüber nachdenken.

-Dein Erzeuger dürfte für die CPU-Last verantwortlich sein, deine Verbraucher sind "nur suboptimal" programmiert…

Gut, dann werde ich mich bald an die Optimierungen setzen.

Hallo Steffen,

Zitat:Dabei will ich nur sichergehen, dass genügend Bytes im Buffer sind. Außerdem soll der Buffer nicht vollaufen. Wenn ich das richtig sehe, dann ist der Buffer schon nach 0,01452 Sekunden voll (3MBaud Rate, 11 Bit pro Symbol und 3640 Symbole)

Indem du dem VISARead sagst, wieviele Daten es lesen soll, hast du auch schon die Frage nach genügend Daten im Buffer erledigt…

Zitat:Offenbar kann man der Funktion keine bruchteile von Millisekunden übergeben. Hm irgendwie schlapp...

1. Das Verhalten der Funktion ist in der Kontexthilfe beschrieben. Die hast du doch gelesen, oder?
2. Windows bietet nur einen Millisekunden-Timer, auf den LabVIEW hier zugreift. Ist also eher ein Problem des OS…
3. Du kannst auf einem nicht-realtime-Windows-PC sowieso nicht genau im µs-Bereich warten…
4. Auch das Warten auf 0ms kann sinnvoll sein - die Schleife erzeugt dann keine 100%ige CPU-Last mehr…

Zitat:Kennst du eine Alternative?

Die brauchst du hier nicht - und sie wäre wg. Punkt 3 sowieso hinfällig…
Entweder hast du mehrere Bytes im Buffer stehen, dann kannst du sie auch in einem Rutsch lesen - oder der Buffer ist leer, dann wartet das VISARead gemäß deinem TimeOut. Wozu also eine Wartefunktion?

Zitat:An dieser Stelle suche ich den Beginn des Datenpakets. Dabei sendet der µC einmal das Byte 0x80 (128). Anschließend kommen weiter 3960 Bytes, die die Daten enthalten. Das könnte man sicherlich optimieren, allerdings weis ich nicht so recht wie...

Indem man die empfangenen Daten in einem String/U8-Array sammelt und dann nachgelagert die Datenpakete anhand dieser Kennung auftrennt…

Zitat:Hm, ich hätte gerne das Schreiben der Daten parallel zum Anzeigen. Da muss ich mal drüber nachdenken.

Sinnvoll ist auch das Studium der LabVIEW-Hilfe, der mitgelieferten Beispiele und der Links in meiner Signatur…

Zur Erklärung:
VISA-Read wartet, wenn du eine Anzahl von Bytes anschließt und den Termination-Char auf FALSE gesetzt hast, entweder solange, bis der READ-Timeout abgelaufen ist oder bis die Anzahl der gewünschten Bytes im Buffer vorliegt. Deine ganzen "Bytes at Port" in ungebremsten WHILE-Loops kannst du dir IMHO (und Gerds HO) also sparen.

Und nein, es gibt kein Wait < 1ms auf Windows Ebene.

Zwecks Schreiben parallel zur Anzeige: Mögliche Lösung: 2 Queues. Nachteil: So wie du es jetzt aufgebaut hast, machst du dann auch 2x die Decodierung, was natürlich überflüssig ist. Also vielleicht nach Decodierung in einer weiteren Queue die Daten an den Schreib-Prozess weitergeben.

Gruß, Jens

Danke für eure Antworten!

Das mit <1µs macht so gesehen natürlich Sinn und kann ich mir also auch sparen.

Die "Bytes at Port" Abfragen hab ich nun ganz rausgeschmissen.

Jetzt liegt die gesamt Auslastung bei ca. 85%. Nach dem Start des VIs geht die Auslastung durch Labview auf ca. 62% hoch. Etwa 30-60s später sinkt die Auslastung langsam unter 50% und dann läuft das VI auch vernünftig.
Ist die Auslastung zu hoch, verteilt sich diese vermutlich auf beide Kerne. Dabei gibt es deutliche Fehler in der Anzeige der Messwerte!

Könnt ihr mir nochmal mit dem Decimate helfen? Ich finde das einfach nicht in der deutschen Palette...

Anzeige

Hallo Steffen,

Kontexthilfe aktivieren und mit der Maus über die Funktionen in der Array-Palette fahren. Die Hilfe zeigt auch den englischen Namen der Funktion an!
QuickDrop sollte den englischen Namen auch kennen…

Decimate1DArray

Ich würde erst mal nur die Datenerfassungs-Schleife laufen lassen, ohne die Daten zu verwenden, um die CPU-Auslastung zu beobachten. Natürlich mit den Abspeckungen, über die hier schon diskutiert wurde. Hier ein Vorschlag mit weiteren Vereinfachungen:

  Daten lesen 3.vi (Größe: 13,59 KB / Downloads: 255)

Die Funktion "Bytes am Port" braucht man übrigens nur selten, da die Visa-Lese-Funktion das mit beinhaltet: Es wird so lange gewartet, bis die am Eingang angelegte Anzahl Bytes im Puffer ist. Nichtdestotrotz wird die Funktion hier im LVF von 110% aller Anfänger exzessiv verwendet.
Was ist denn das für phänomenales serielles Gerät, welches 3M Baudrate schafft? Verdächtig ist mir auch die zu gerade Zahl. Im Windows Gerätemanager kann man die Eigenschaften abfragen. Mein FTI USB to Serial Komverter zeigt da gerade mal 921600 Baud als höchste Rate an.