100% CPU-Auslastung, trotz Wartezeit?

' schrieb:Braucht man nicht, verlass dich da ganz auf den Treiber. Hast du das dann mit dem Metronom gemacht?

Mal so mal so, wobei der Metronom im Prinzip keine wirkliche Wartezeit wäre bzw. je nach Situation. Aber ich glaube sogar, dass ich einmal ohne Verzögerung gearbeitet habe und das auch gut ging.

' schrieb:Ein einfaches, paralles Warten (ohne Datenflussabhaengigkeiten) von z.B. 49ms sollten doch fuer deine Anwendung hinhauen... keine Ahnung was du sonst noch mit den Daten machts... aber ich wuerde schaetzen, dass du mit 49ms so gut wie nie im busywait haengst.

Nein, das wäre der größte Mist, den ich machen könnte. Dann kann ich mir den FIFO schenken, da ein voll gelaufener FIFO nie abgearbeitet werden kann. Das liegt daran, dass ich mit 50 ms Werte rein schreibe und durch die Wartezeit auch nur mit 49 ms bzw. 50 ms auslese.
Ohne Verzögerung dauert das Auslesen und verarbeiten ca. 6 ms und das sollte nach Möglichkeit so bleiben. Ein FIFO, der etwas voller ist, wird so wieder zügig geleert.

Anzeige

Edit: Deleted. /EOM

Guten Morgen

' schrieb:Ich dachte du schreibts mit 1khz werte rein und nicht mit 20 hz?

Sorry, habe mich falsch ausgedrückt.

Ich schreibe in den FIFO mit 1 kHz und lese über FIFO.Read immer 50 Werte auf einmal aus. D.h. es dauert 50 ms, bis der FIFO so voll ist, dass ich ihn auslesen kann.

' schrieb:verarbeiten duerfte der fifo nicht voller werden. im gegenteil... pro zyklus ca 1 leerer bis der grossteil des wartens wieder ein busy wait im dma-read ist.

Dann kommt noch die Verarbeitung der Daten dazu, die länger als 1 ms dauert und schon läuft der FIFO kontinuierlich voll.
Aber selbst wenn alle 50 ms ein Wert der FIFO um einen Wert kürzer wird, ist das zu langsam.

Wenn eine Ethernet-Kommunikation (die da integriert ist) z.B. mal 200 ms benötigt, dann habe ich keine Chance, den FIFO in kurzer Zeit wieder zu leeren.

' schrieb:anderer ansatz... timed loop mit 50ms und pro zyklus alle vorhandenen werte auf einmal auslesen? oder bist du auf exakte 50er bloecke angewiesen bzw. befuerchtest du probleme mitm memory manager?

Zuerst verwendete ich eine TimedLoop, wobei ich da auch immer nur 50 Werte verarbeitet habe. Und genau dann ginge die Timed Loop nicht.
Wenn ich alle Werte auslesen, würde das theoretisch funktionieren. Ich bin mir nur nicht sicher, ob das einen Vorteil bringt.

Ich habe mich für 50er-Blöcke entschieden, da ich so ca. weiß, wie lange die Verarbeitung der Daten braucht.
Wenn da mal 500 Werte auf einmal kommen sollten, könnte ich mir vorstellen, dass dann irgendwas deutlich langsamer wird, da die Werte z.T. in Arrays landen und die finde ich persönlich sehr langsam ab einer bestimmten Größe (auch wenn ich das Array vorher initialisiere und dann nur Werte ersetze).

Grüße

Ich hab bisher hier nur mitgehört und muss doch mal, da ich bisher noch nie mit NI-LV-FPGAs gearbeitet habe, folgende Frage stellen.

' schrieb:Ich schreibe in den FIFO mit 1 kHz und lese über FIFO.Read immer 50 Werte auf einmal aus. D.h. es dauert 50 ms, bis der FIFO so voll ist, dass ich ihn auslesen kann.

Heißt dass, dass der FIFO nur 50 Werte aufnehmen kann und dann überläuft?

Oder ist es doch so, wie ich mir das denke: Der FIFO selbst ist das Doppelte lang, also 100 Werte spricht 100ms (oder so), und soll einmal pro 50ms ausgelesen werden. Wenn dem so ist, spielt es doch gar keine Rolle, wenn das Verarbeiten der 50 Werte maximal 10ms dauert. Diese Verarbeitungszeit hat dann eine obere Streugrenze von 50ms, die ja hoffentlich nie auftritt, was wiederum durch das RT gewährleistet werden soll. Soweit der eine Sachverhalt. Sehe ich das richtig?

Dich interessiert aber mehr, dass das "Warten auf 50 Werte im FIFO" "CPU-Zeit" beansprucht. Ein FPGA sollte doch aber 100% laufen können. Zumal in einem FPGA das "Programm" hardware-verdrahtet ist. Gerade in einem FPGA, also mit Hardware-Verdrahtung, kann ich doch in idealer Weise theoretisch unendlich viele parallele "Prozesse" ablaufen lassen. Da stört es doch die 99 anderen Prozesse nicht, wenn der eine Prozess, der die Anzahl der Zeichen im FIFO prüft, in einer Dauerschleife wartet. Diese meine Gedanken würden natürlich nur stimmen, wenn das FPGA aus "verdrahteten Logikgattern, Macros, Tables etc." besteht - und nicht aus einem "CPU-Kern, der einen Microcode verarbeiten muss".

Kann wer auf letzte (implizite) Frage, CPU-Kern oder Macro, eine kurze Antwort geben?

Hallo

' schrieb:Heißt dass, dass der FIFO nur 50 Werte aufnehmen kann und dann überläuft?

Nein, ich habe die Größe aktuell auf 1023 Elemente gesetzt.

' schrieb:Wenn dem so ist, spielt es doch gar keine Rolle, wenn das Verarbeiten der 50 Werte maximal 10ms dauert. Diese Verarbeitungszeit hat dann eine obere Streugrenze von 50ms, die ja hoffentlich nie auftritt, was wiederum durch das RT gewährleistet werden soll. Soweit der eine Sachverhalt. Sehe ich das richtig?

Genau. Daher ist die vorgeschlagene, feste Verzögerung von 50 ms, schlecht.

' schrieb:Kann wer auf letzte (implizite) Frage, CPU-Kern oder Macro, eine kurze Antwort geben?

Wie das genau ist, weiß ich nicht, aber auf dem FPGA läuft kein Betriebssystem, sodnern direkt der Bit-Code. D.h. es ist eine echte parallele Abarbeitung möglich.

' schrieb:ich habe die Größe aktuell auf 1023 Elemente gesetzt.

Naja, je mehr je besser. Aber gleich das zwanzigfache?

Zitat:Daher ist die vorgeschlagene, feste Verzögerung von 50 ms, schlecht.

Das sehe ich genau so.

Die nächste Frage, die sich mir stellt: Warum interessiert dich eigentlich die "CPU-Auslastung"? Aus deinem Ansinnen müsste ich schließen, dass das FPGA-Programm in einem Simulator läuft - und der macht genau das, was das FPGA auch macht: kontinuierlich laufen. Das ist auf der einen Seite zwar gut so, hat aber den dummen Seiteneffekt, dass der Simulator die CPU-Last, die es auf FPGA eigentlich gar nicht gibt, hochschraubt - was rückwärts sich natürlich auf parallele Prozesse auswirken könnte - was es im FPGA aber auch gar nicht gibt. Sehe ich das richtig?

Würde das mit dem Simulator so stimmen, wie ich mir das ausgedacht habe, dann ist das mit der CPU-Auslastung und den Folgen darauf aber ein Problem der Testumgebung, nicht des Zielsystems. In diesem Fall würde ich eine Wartezeit integrieren, mit der die CPU-Auslastung auf z.B. 50% zurückgeht. Das sollte für die Testumgebung ausreichend sein, schadet im Zielsystem aber wohl nichts.

Anzeige

' schrieb:Naja, je mehr je besser. Aber gleich das zwanzigfache?

Das war erstmal fürs Testen. Ich kann im Programm selbst eine Verzögerung aktivieren zu Debug-Zwecken. Da sehe ich dann schön, wie der FIFO voll läuft und bei Deaktivierung der Verzögerung abgearbeitet wird.

' schrieb:Die nächste Frage, die sich mir stellt: Warum interessiert dich eigentlich die "CPU-Auslastung"? Aus deinem Ansinnen müsste ich schließen, dass das FPGA-Programm in einem Simulator läuft [...]

Nein, das läuft richtig im FPGA. Da ist nichts simuliert.
Die CPU-Auslastung interessiert mich deshalb, weil ich aktuell 2 Sensoren einlese, später ca. 16.
Bei einer Verzögerung sinkt die CPU-Last und das ist sicher besser als immer mit 100% zu laufen. Daher wundert mich, dass FPGA.Read die CPU auch beim Warten auslastet.

Ich meine übrigens die CPU-Last des cRIOs und nicht des Host-PCs. Also es läuft kein Simulator.

' schrieb:[...] was rückwärts sich natürlich auf parallele Prozesse auswirken könnte - was es im FPGA aber auch gar nicht gibt. Sehe ich das richtig?

Öhm. Also du siehst es falsch, da nichts simuliert wird. Der FPGA-Code wird im FPGA wirklich parallel ausgeführt.

Edit: Deleted. /EOM

Hallo, danke.

' schrieb:Aha, noch eine Detailinfo mehr... d.h. das zwischen "alle Daten erhalten" und "Daten verloren, weil Netzwerk zickt" nur der DMA-FIFO liegt? HW- und Netzwerk-IO in einer Schleife?

Nein, die Ethernet-Geschichte ist in einer parallelen Schleife und die Ethernet-Daten transferiere ich über Queues in die Mess-Schleife und von dort wieder zurück.
Nur werden die Schleifen auf einer Single-Core-CPU nicht wirklich parallel ausgeführt. Daher kann ich schlecht einschätzen, in wie weit das "parallel" abläuft.
Vielleicht sind die 100%-CPU-Last auch nicht schlimm. Das muss ich mal testen.

Per Ethernet kommen im Endeffekt die Infos "Start" und "Stop" bzw. "Messende" sende ich zurück.

Edit: Deleted. /EOM