Pausieren von parallel ablaufenden Producer/Consumer Schleifen

Hallo
@dimitri84 und IchSelbst: Danke für die Hinweise. Das kann ich sicherlich irgendwann mal brauchen, Sieht gut aus.
Allerdings ist bei mir eher das speichern und archivieren der DatenMENGE mit handelsüblichen Methoden ein Problem, das mich aber grad net kratzen soll. Die Messungen können mehrere Tage laufen, da läuft mir alles über. von der Zeit die ich anschließend fürs Post processing benötige, will ich mal gar net reden. Daher brauch ich auch die von mir geschriebene "Kompression" der Messdaten, die, kurz gesagt, nix anderes als ne Signalmittelung ist.
Trotzdem vielen herzlichen Dank für Eure geilen Vorschläge

Gruß
Karl

Anzeige

' schrieb:Da fällt mir gerade ein:
Auch wenn die Prozesskette zu langsam ist, muss sich Prozess 1 eigentlich um gar nichts kümmern: Einfach in die Queue reinschreiben. Wenn die Queue bereits voll ist, wird der letzte Puffer einfach ignoriert und geht automatisch verloren.

' schrieb:Nur kleine Ergänzung: "Automatisch" geht nichts verloren. Man muß zum Reinschreiben schon die Funktion "Element einfügen (verlustbehaftet)" verwenden und nicht die ansonsten übliche Funktion "Element einfügen"

Und mir fällt jetzt beim Lesen ein paar Tage später noch was ein:
Man muß gar keine Daten wegwerfen. Erzeuger- und Verbraucherschleife synchronisieren sich immer, ganz gleich welche von beiden schneller ist. Die langsamere der beiden Schleifen bestimmt den Takt. Man muß zum Hineinschreiben nicht das VI "Verlustbehaftet" nehmen und Daten verloren gehen lassen.

Verbraucher ist schneller: In der Verbraucherschleife wartet die Funktion "Element entfernen" immer solange, bis wieder ein Element im Puffer ist. (genügend großes Timeout vorausgesetzt)

Erzeuger ist schneller: Die Puffer läuft allmählich voll. Wenn er voll ist, dann wartet die Funktion "Element hinzufügen" so lange, bis wieder Platz für 1 Element ist. (genügend großes Timeout vorausgesetzt)

Natürlich kann es da trotzdem Probleme geben. Eine kontinuierliche DAQ-Datenerfassung läßt sich z.B. nicht durch Anhalten der Schleife stoppen.

' schrieb:Natürlich kann es da trotzdem Probleme geben. Eine kontinuierliche DAQ-Datenerfassung läßt sich z.B. nicht durch Anhalten der Schleife stoppen.

Eben, eine Lösung ist das nicht, denn dann läuft der Kartenpuffer ganz schnell voll.

' schrieb:Eben, eine Lösung ist das nicht, denn dann läuft der Kartenpuffer ganz schnell voll.

Kann er ja. Was ich rüberbringen wollte war, daß der Queuepuffer nicht über läuft und von daher keine Daten verloren gehen.

Aleph1 schreibt nicht, wie er die Daten aufnimmt. Wenn die Daten softwaremäßig oder nicht kontinuierlich getriggert werden dann ist das Anhalten der Datenerfassung kein Problem. Wenn aber die Erfasung kontinuierlich mit einer DAQmx NI-Karte mit internem Takt erfolgt, dann läuft die ganze Datenerfassung autark ab und kann nicht so einfach zum Pausieren gebracht werden. Das wollte ich mit dem zitierten Satz andeuten.

Wir wissen auch sonst nichts über den Hintergrund des Problems, also z.B. nicht, ob das Pausieren der Datenerfassung oder das Wegwerfen von Daten überhaupt mit der Aufgabenstellung kompatibel ist. Somit bleiben alle Antworten und Lösungsvorschläge, und so auch die meinigen, letztlich spekulativ.

Und wenn ich weiter spekulieren darf: Die vermeintliche Langsamkeit der Datenverarbeitung gegenüber der Datenerfassung hat ihre Ursache fast immer in behebbaren Anfängerfehlern, z.B. Einzelverarbeitung jedes neuen Datenpunktes, vor allem aber in irrsinnig hohen Updateraten in Diagrammen und Anzeigen.

Servus,

Zitat:Aleph1 schreibt nicht, wie er die Daten aufnimmt. Wenn die Daten softwaremäßig oder nicht kontinuierlich getriggert werden dann ist das Anhalten der Datenerfassung kein Problem. Wenn aber die Erfasung kontinuierlich mit einer DAQmx NI-Karte mit internem Takt erfolgt, dann läuft die ganze Datenerfassung autark ab und kann nicht so einfach zum Pausieren gebracht werden.

zum Schema der Datenaufnahem ist folgendes zu sagen:
Ich nehme einen Wellenzug mit bis zu 200.000 Einzelwerten auf. Der Start der Datenaufnahme ist getriggert und dann werden 200.000 Einzelwerte kontinuierlich eingelesen und anschließend die Datenaufnahme beendet.
Das ist dann ein Element der Queue welches weiterverabeitet werden muss. 200.000 Datenpunkte werden dabei in ca. 0.2s eingelesen, können/sollen aber auch schneller eingelesen werden (in Zukunft). Diese 0.2s geben mir die Zeitauflösung meines abschließenden Messergebnisses.
(Zur Info: Ich arbeite auf dem Gebiet der Diodenlaserspektroskopie und brauche einfach diese Datenmengen um vernünftige Ergebnisse zu erhalten.)

Zitat:Und wenn ich weiter spekulieren darf: Die vermeintliche Langsamkeit der Datenverarbeitung gegenüber der Datenerfassung hat ihre Ursache fast immer in behebbaren Anfängerfehlern, z.B. Einzelverarbeitung jedes neuen Datenpunktes, vor allem aber in irrsinnig hohen Updateraten in Diagrammen und Anzeigen.

Aus diesem Queueelement wird im zweiten Prozess die Autokorrelation berechnet. Das dauert einfach seine Zeit und ich denke dass diese Berechnung der Flaschenhals ist. Je länger der Wellenzug ist, desto länger benötigt die Autokorrelation zur Berechnung, allerdings sinkt auch die Zeitauflösung (also die Zeitdauer des Gesamtwellenzuges erhöht sich).
Auf Diagramme kann ich weitestgehend verzichten, allerdings ist das ein guter Punkt den ich vollkommen vergessen hatte.

Zitat:Wir wissen auch sonst nichts über den Hintergrund des Problems, also z.B. nicht, ob das Pausieren der Datenerfassung oder das Wegwerfen von Daten überhaupt mit der Aufgabenstellung kompatibel ist. Somit bleiben alle Antworten und Lösungsvorschläge, und so auch die meinigen, letztlich spekulativ.

Das Pausieren bzw. Wegwerfen einzelner Daten (also Gesamtwellenzüge) kann bei genügend hoher Zeitauflösung des Messergebnisses (0.2s und besser) in Kauf genommen werden, ist aber stark von der meiner aktuellen Anwendung und Fragestellung abhängig.

Ich seh schon, das ist mit mehr Detailfragen behaftet, als ich eigentlich dachte.
Aber ihr helft mir sehr weiter.

Gruß
Karl

Ich würde die Mittelung der Daten (Kompression) direkt im ersten Prozess ausführen und die Daten "dezimiert" weitergeben, somit sollte die Senke (Abspeicherung) schneller laufen. Die Abspeicherung würde ich nicht zeilenweise ausführen, sondern blockweise (dann läuft es IMHO besser).

Anzeige

Dann verliere ich aber massiv an Zeitauflösung. Dann nehm ich lieber den kleineren Flaschenhals der Datenspeicherung in Kauf.
Die Daten werden allerdings im Binärformat abgespeichert, daher ist Zeilen oder Spaltenweise abspeicherung irrelevant.

Gruß
Karl

So viel geschrieben und doch so wenig preisgegeben. Welche Karte benutzt du? Eine von NI oder einem Drittanbieter? Bei 1MHz Sampling-Rate kann man Softwaretakt wohl ausschließen ...

Also holst du Datenpakete à 200.000 Samples ab?

' schrieb:Das ist dann ein Element der Queue welches weiterverabeitet werden muss. 200.000 Datenpunkte werden dabei in ca. 0.2s eingelesen, können/sollen aber auch schneller eingelesen werden (in Zukunft). Diese 0.2s geben mir die Zeitauflösung meines abschließenden Messergebnisses.

Circa 0.2s?! Wieso circa?

Zitat:Wegwerfen einzelner Daten (also Gesamtwellenzüge) kann bei genügend hoher Zeitauflösung des Messergebnisses (0.2s und besser) in Kauf genommen werden, ist aber stark von der meiner aktuellen Anwendung und Fragestellung abhängig.

Unter zeitlicher Auflösung verstehe ich das dt. Bei dir 1/1Mhz.

' schrieb:Dann verliere ich aber massiv an Zeitauflösung. Dann nehm ich lieber den kleineren Flaschenhals der Datenspeicherung in Kauf.

Ok, dann hilft ein stärkerer PC, Postprocessing oder verteilte Anwendung.

' schrieb:Die Daten werden allerdings im Binärformat abgespeichert, daher ist Zeilen oder Spaltenweise abspeicherung irrelevant.

Ich habe nur formell ausgesagt, also dann binäre Blöcke und nicht einzelne Pakete.

Servus,

@dimitry84

Zitat:Welche Karte benutzt du? Eine von NI oder einem Drittanbieter?

Ja, ich hab eine Karte von NI drin, bzw. sind alle Karten die wir verwenden (applikationsabhängig) von NI. Nagel mich jetzt nicht fest welche genau, ich bin grad unterwegs und hab die genaue Bezeichnung grad net parrat.

Zitat:Also holst du Datenpakete à 200.000 Samples ab?

Ja, genau.

Zitat:Circa 0.2s?! Wieso circa?

Ja, sind dann schon ganu 0.2s. Sorry für die unklare Ausdrucksweise.

Zitat:Unter zeitlicher Auflösung verstehe ich das dt. Bei dir 1/1Mhz.

Das ist die zeitliche Auflösung meines Datensamplings, also das dt, wie du schon sagst. Die zeitliche Auflösung der Messung (meine Zeitreihe) sind die 0.2s (Zeitdauer des Wellenzuges). Ein Wert der Zeitreihe setzt sich aus 200.000 Datenpunkten zusammen bzw. wird aus diesen Punkten berechnet.

@eg

Zitat:Dann verliere ich aber massiv an Zeitauflösung. Dann nehm ich lieber den kleineren Flaschenhals der Datenspeicherung in Kauf.

Zitat: Ok, dann hilft ein stärkerer PC, Postprocessing oder verteilte Anwendung.

Ja, genau, deswegen auch die Verteilung auf mehrere Prozessoren. Das scheint mir zunächst mal der einfachste Zugang.

Zitat:Ich habe nur formell ausgesagt, also dann binäre Blöcke und nicht einzelne Pakete.

Ah OK, dann ist das klar.

Gruß
Karl