21.06.2010, 17:46
|
Lucki
Tech.Exp.2.Klasse
Beiträge: 7.699
Registriert seit: Mar 2006
LV 2016-18 prof.
1995
DE
01108
Deutschland
|
Pausieren von parallel ablaufenden Producer/Consumer Schleifen
' 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.
|
|
|
21.06.2010, 19:30
(Dieser Beitrag wurde zuletzt bearbeitet: 22.06.2010 07:12 von Lucki.)
|
Lucki
Tech.Exp.2.Klasse
Beiträge: 7.699
Registriert seit: Mar 2006
LV 2016-18 prof.
1995
DE
01108
Deutschland
|
Pausieren von parallel ablaufenden Producer/Consumer Schleifen
' 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.
|
|
|
24.06.2010, 11:36
(Dieser Beitrag wurde zuletzt bearbeitet: 24.06.2010 11:58 von Aleph1.)
|
Aleph1
LVF-Gelegenheitsschreiber
Beiträge: 51
Registriert seit: Sep 2005
7.1 + 8.6.1
2005
de_en
69120
Deutschland
|
Pausieren von parallel ablaufenden Producer/Consumer Schleifen
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
|
|
|
24.06.2010, 11:48
(Dieser Beitrag wurde zuletzt bearbeitet: 24.06.2010 11:49 von eg.)
|
eg
LVF-SeniorMod
Beiträge: 3.868
Registriert seit: Nov 2005
2016
2003
kA
66111
Deutschland
|
Pausieren von parallel ablaufenden Producer/Consumer Schleifen
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).
|
|
|
24.06.2010, 12:03
|
dimitri84
Astronaut
Beiträge: 1.496
Registriert seit: Aug 2009
2020 Developer Suite
2009
DE_EN
53562
Deutschland
|
Pausieren von parallel ablaufenden Producer/Consumer Schleifen
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.
„Sag nicht alles, was du weißt, aber wisse immer, was du sagst.“ (Matthias Claudius)
|
|
|
24.06.2010, 12:15
|
eg
LVF-SeniorMod
Beiträge: 3.868
Registriert seit: Nov 2005
2016
2003
kA
66111
Deutschland
|
Pausieren von parallel ablaufenden Producer/Consumer Schleifen
' 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.
|
|
|
24.06.2010, 12:38
|
Aleph1
LVF-Gelegenheitsschreiber
Beiträge: 51
Registriert seit: Sep 2005
7.1 + 8.6.1
2005
de_en
69120
Deutschland
|
Pausieren von parallel ablaufenden Producer/Consumer Schleifen
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
|
|
|
| |