Handhabung großer Datenstreams

Hi,

bevor ich mich jetzt weiter durch zig Suchseiten wühle, die das nur am Rande behandeln:

Meine Datenquelle ist ein NI Digitizer, der mir als Stream Daten auswerfen soll. Vermutlich wird es darauf hinauslaufen, dass ich die vor einer Weiterverarbeitung erstmal "zwischenspeichern" muss (auf Festplatte, oder eventuell auch per LAN an einen anderen Rechner), da Datenverarbeitung auf dem Messrechner meine erreichbare Samplerate drastisch drückt (und die ist eh schon bei unter einem Fünftel dessen was der Digitizer kann, da die USB Schnittstelle nicht mehr hergibt).

Mein Problem ist daher:

Ich Streame vom Digitizer fortlaufend das Signal auf einem Kanal. Entsprechend erhalte ich jede Sekunde ~8Mb (entsprechend der beim testen maximal stabil erreichbaren Sample Rate von 8M Samples/s) Daten in Paketen von I8 Arrays "unbekannter" Länge (da ich den Buffer des Digitizers immer nach Möglichkeit komplett leere um ein möglichst schnelles Auslesen zu garantieren; vorteilhaft dafür scheint es zu sein möglichst große Pakete zu lesen; die Optimierung läuft anschließend darauf hinaus die Sample Rate so zu wählen, dass der Buffer im Digitizer nicht überläuft; im praktischen Betrieb habe ich dann am Anfang der Messung Arrays konstanter Länge, (da Messung und Daten holen scheints nicht exakt gleichzeitig gestartet werden) und irgendwann den Buffer leer gemacht und dann nur noch Arrays nicht vorhersagbarer Länge. (Meist >100k Werte).

Da das ganze zeitkritisch ist schreibe ich das aktuell wie gesagt einfach stumpf weg. Denke hier kann man auch relativ leicht darauf optimieren keine unnötigen Datenkopien etc. zu erzeugen und das möglichst effizient zu machen.
Das Problem kommt danach: Die Signale müssen anschließend auch noch verarbeitet werden und dazu muss ich das fortlaufende Signal (zumindest stückweise) wieder zusammensetzen und durch verschiedene Filter / Verarbeitungsroutinen jagen. Im besten Fall krieg ich die Datenmenge dadurch auch relativ schnell reduziert (aus den gesamten Datenpunkte interessieren nur Ausschnitte, allerdings müssen die softwareseitig identifiziert werden). Nur muss ich die bis dahin erstmal irgendwie handhaben und sinnvoll im Speicher aufbewahren etc. pp.

Leider (in dem Fall) hat Labview ja Datenfluss, deswegen muss man ja immer aufpassen wenn man kopien vermeiden will. Wie geht man sowas dann am besten an? Daten über eine Queue von A nach B weiterreichen? In dem Zusammenhang: Funktioniert eine Queue als Referenz oder wird in die Queue eine Datenkopie geschrieben?
Im Prinzip denke ich wäre die Queue zumindest organisatorisch die beste Lösung, da die es erlauben sollte sehr schön Datenproduktion und Verarbeitung zu synchronisieren; aber wenn ich da jedes mal kopiere dann dürfte das ja massiv Zeit kosten.

Welche Konzepte sollte man sich vielleicht noch anschauen um sowas möglichst performant (in dem Fall: schnell) zu lösen?

Ich gehe mal nur auf 2 Punkte ein:

1) Für schnelles Speichern bietet sich TDMS an. Du kannst dich hierbei auch mit den Advanced TDMS VIs auseinandersetzen.
2) Daten in eine Queue zu übergeben erzeugt in der Regel Datenkopien, da die Queue als Zwischenspeicher für 1 bis x Elemente dient.

Gruß, Jens

(03.06.2015 12:41 )jg schrieb:  2) Daten in eine Queue zu übergeben erzeugt in der Regel Datenkopien, da die Queue als Zwischenspeicher für 1 bis x Elemente dient.

Wie mache ich das dann besser? Einlesen direkt in nen Indikator schieben und eine Referenz darauf übergeben? Die gelesenen Arrays in einem Cluster Kapseln und dann ein Array daraus machen? Das erzeugt doch dann jeweils ne Kopie der gesamten Struktur, wenn ich da mit Build Array was anhänge, oder?

Oder gibt es irgendeine andere Möglichkeit in Labview (unter der Haube) mit Referenzen zu arbeiten?

Schreiben und Lesen in Controls ist nicht gut... da werden zwingend immer Kopien angelegt.
Daten per Queue zu übergeben ist schon recht zielführend, da diese bei richtiger Benutzung keine Kopie anlegen. Dazu gibt's auch Beispiele Stichwort SEQ Single Element Queue (in der Community bei den LV Examples keine Ahnung, aber z.B. im LV Advanced Kurs). In deinem Fall bieten sich natürlich Queues mit mehreren Elementen an. Die Queue sollte größenbeschränkt und der Platz für die Elemente (nach oben abgeschätzt) vorallokiert sein (Prealloc Queue). Falls Du das RT-Modul hast, kannst Du auch die RT-Fifo Funktionen unter Windows nutzen, da müssen die Arrays aber wirklich immer gleich groß sein.
Alternativ könntest Du auch eine Menge DVRs für deine Arraysbrocken anlegen, diese auch wieder vorallokieren und damit einen Ringpuffer bauen.
Da müsstest Du allerdings die Zeigerlogik selbst schreiben, d.h. welche Page als nächste gelesen/beschrieben werden soll.
Oder baust eine DVR mit einem großen Array (vorallokiert) und den Lese/Schreibe-Zeigern (I32s) und schreibst die Arraybrocken per Replace Array Subset.
Dabei musst du allerdings aufpassen, das weder der Producer noch der Consumer die DVR zu lange blockiert.
Allgemein würde ich noch darauf schauen nicht zu kleine Arraystückchen zu transportieren.

Welche Verarbeitungen machst Du denn, bzw. wie groß sind die Datenbrocken die Du dabei im (kontinuierlichen) Zugriff brauchst?

(08.06.2015 10:55 )Kiesch schrieb:  

(03.06.2015 12:41 )jg schrieb:  2) Daten in eine Queue zu übergeben erzeugt in der Regel Datenkopien, da die Queue als Zwischenspeicher für 1 bis x Elemente dient.

Wie mache ich das dann besser? Einlesen direkt in nen Indikator schieben und eine Referenz darauf übergeben? Die gelesenen Arrays in einem Cluster Kapseln und dann ein Array daraus machen? Das erzeugt doch dann jeweils ne Kopie der gesamten Struktur, wenn ich da mit Build Array was anhänge, oder?

Oder gibt es irgendeine andere Möglichkeit in Labview (unter der Haube) mit Referenzen zu arbeiten?

Hi macmarvin,

meine Datenbrocken sind generell nach oben durch den intern im Digitizer zu Verfügung stehenden Speicherplatz beschränkt (beim aktuellen Modell maximal 20Mb oder sowas in der Richtung), da nach füllen dieses Speichers die Datenaufnahme mit Pufferüberlauf abbrechen würde. Entsprechend gibt es auch für beliebige zukünftige Anwendungen immer eine solche obere Grenze (auch wenn die sich noch verschieben könnte). Aktuell haben meine Arrays maximal 5Mb, die meisten sind kleiner.

Das RT Modul habe ich und habe auch schon überlegt ob ich das nutzen sollte bzw. nutzen kann um den Datenaufnahmeprozess in Realtime laufen zu lassen, während ich eine erste Parrallelverarbeitung in einer niedriger priorisierten Schleife in nicht-RT mache. Leider habe ich damit noch keine Erfahrung, wie gut oder schlecht das funktioniert und müsste dann auch dafür sorgen, dass die auf Verarbeitung wartenden Daten parrallel irgendwo gepuffert werden etc. muss ich mal schauen und mit rumprobieren ob ich da zumindest schonmal die Datenmenge verkleinert kriege.
Von wegen Arrays immer gleich groß: Ich hatte auch schon überlegt, ob ich beim Einlesen eine Zwischenverarbeitung durchführe die gleich große Arrays aus den Daten erzeugt, allerdings muss ich dann zwingend eine Datenkopie anfertigen (da ich erst aus der Datei einlese und die Daten dann weiter zerhacken bzw. zusammenfügen müsste). Insofern: Leider kann ich ohne (meiner Meinung nach) zu viel Overhead bei der Verarbeitung keine identisch großen Arrays generieren.

@DVRs

Wusste bisher garnicht, dass man sich auf ein "Kabel" eine Referenz holen kann. Das sieht für meine Zwecke eigentlich ganz vielversprechend aus. Sehe ich das richtig, dass der Speicherplatz dann auch so lange lebt, bis ich den explizit freigebe? Ich könnte also quasi auch in einer Schleife lesen, das "Kabel" in eine Referenz wandeln
die ich über eine Queue in die Verarbeitung weitergeben kann und im nächsten durchlauf wieder lesen etc. pp (ohne da in den gleichen Speicher geschrieben wird)?

Dann könnte man den Producer nämlich schön über die Queue Größe auf die Geschwindigkeit des Consumers einbremsen (ka; maximal 10 Elemente, dass sollte der Consumer nicht leer kriegen bevor der Producer nachliefert ).

Die eigentlichen Stücke die ich dann relativ schnell in der Verarbeitung draus machen werde dürften dann jeweils ~500-1000 8Bit Werte enthalten und eine feste größe haben. Habe in meiner Anwendung ein kontinuierliches Messsignal, auf dem im Messprozess Peaks auftreten, die ich identifizieren und ausfiltern muss um die dann in der Weiterverarbeitung in einen Messwert umzurechnen. Und wie gesagt, durch die große Datenmenge muss die identifikation möglichst schnell gehen. Hat man das erstmal, sollte der Datendurchsatz um einen Faktor 10-100 sinken, da der größte Teil des Messsignals für die Auswertung uninteressant ist.


Na ja also wie gesagt: Ich probier dann jetzt mal mit DVRs rum und geb nochmal Rückmeldung. Und ich werd deinen Beitrag schonmal als Lösung markieren, da mir das sehr weitergeholfen hat - danke :-)