zwei Schleifen oder eine Schleife

Guten Abend!

Ich habe ein Problem, wo ich grade etwas auf dem Schlauch stehe. Ich habe heute mit jemand anders diskutiert, ob man Messwerterfassung und Abspeichern in eine Schleife setzt oder in zwei Schleifen und diese miteinander verbindet, z.B. mittels Queues.

Folgende Randbedingungen:
Die Messwerte kommen per Ethernet aus einem Echtzeitsystem. Das Echtzeitsystem hat einen sehr großen Ringspeicher, der kontinuierlich gefüllt wird.

Nach meinen bisherigen LabView-Erfahrungen würde ich den Prozess des Auslesens und des Abspeicherns in zwei Schleifen realisieren. Die Auslesung aus dem Echtzeitsystem würde ich mit einem Timer versehen, so dass in regelmässigen Abständen - z.B. alle 100ms der Ringspeicher komplett gelert wird, dann bekomme ich ein Array mit Messwerten und dieses Array würde ich an eine zweite Schleife mittels einer Queue senden, um dort den Abspeicherprozess zu erledigen.

Ich sehe folgende Vorteile in dieser Variante:
- die Proesse von Abspeichern und Daten holen sind "dynamisch" voneinander getrennt
- ich kann die Abspeichereinheit später leichter anpassen - z.B. wenn die Datei zu groß wird und eine zweite her muss
- eventuelle Verzögerungen z.B. durch das Schreiben auf die Festplatte würden vermieden werden (jede Schleife hat ihre eigene Dynamik, die Queue puffert nochmal)
- wenn eine Messung viele Stunden dauert, dann muss die Datei nicht ständig geöffnet sein, wenn man beim Auslesen z.B. 10.000 Werte bekommt in einem Datenpaket, dann wird die Datei kurz geöffnet, die Daten aus dem Array gespeichert, dann die Datei wieder geschlossen - ich weis auch garnicht was passiert, wenn eine Datei noch offen ist und der Rechner abstürzt

Folgende Gegenargumente wurden benannt:
- es sind zwei Speicher vorhanden - in dem Computer durch die Queue und in dem Echtzeitsystem (Ringspeicher)
- der Prozess vom Datenholen und vom Abspeichern soll in einem Zug durchgeführt werden mit höchster Priorität, aber immer nur dann, wenn er dran ist. Während der Wartezeit nicht. Durch die Variante mit den zwei Schleifen und die Queue ist dies nicht gewährleistet, sondern die Queue liefert zeitverzögert den Datensatz an die zweite Schleife
- wenn z.B. irgendwelche Verzögerungen auftreten - z.B. wenn das Datenaufdiefestplatteschreiben länger dauert, dann wird dies schon durch den im Echtzeitsystem vorhandenen Ringspeicher ausgeglichen
- das Problem mit dem Öffnen und schließen kann man so umgehen, wenn man den Prozess des Öffnens vor das Datenauslesen setzt, da auch z.B. 8445 Messwerte bekommt und die dann auch in einem Rutsch abspeichert

Ich habe auch später noch in meinem LabView-Buch noch nach einer Lösung gesucht, welche Variante empfohlen wird (habe das Buch Einführung in Labviev 5.0 von Ergen Mertin), aber irgendwie nichts gefunden.

Ich wie gesagt würde von meinem Bauchgefühl heraus die erste Variante mit voneinander entkoppelten Datenholen- und Abspeichern vorziehen, kann aber auch die Argumente meines Chefs verstehen, dass hierbei nochmal eine Queue neu geschaffen wird und ein zweites Puffern der Messwerte nicht nötig ist.

Ich hab mir später auch gedacht, dass meine Variante vielleicht dann sinnvoll ist, wenn die Daten sehr schnell aus einem Messgerät ausgelesen werden müssen, wenn der Ringspeicher in dem Gerät nicht groß genug ist und dann Verzögerungen durch Speicherprozesse z.B. zum Überlauf beim Datenerfassungsgerät die Folge sein könnten.

Ich würde mich sehr freuen, wenn mir ein paar Spezialisten von Euch dazu ein paar Argumente geben könnten, welche Variante denn nun geeigneter wäre, weil es zwei unterschiedliche Programmieransätze sind und wenn ich einen andere Variante nehme als die von meinem Chef, dann muss ich das auch gut begründen können, was ich aber zur Zeit nicht kann - ich würde es nur aus dem Bauchgefühl heraus so machen wie von mir beschrieben. Aber irgendwie erscheinen mir auch die anderen Argumente schlüssig.

(20.02.2013 23:59 )Hasenfuss schrieb:  Ich habe ein Problem, wo ich grade etwas auf dem Schlauch stehe.

Hallo Hasenfuss,

warum steht hier im Forum eigentlich jeder 2. Fragesteller auf dem Schlauch oder sieht den Wald vor lauter Bäumen nicht?!
Du und dein Chef habt euch doch dezidierte Gedanken über die o.a. Fragestellung gemacht und somit lediglich das Dilemma, dass jeder einen anderen Standpunkt vertritt - etwas mehr Selbstbewusstsein!

Nun aber zum eigentlichen Problem, das aus reichlich Lesetext besteht

Ich würde, ohne deine Systemanforderungen genau zu kennen, grundsätzlich auch dazu raten, eine Producer / Consumer - Struktur aufzubauen. Du schreibst, das Echtzeitsystem hat einen sehr großen Ringspeicher. Sehr ist meist sehr relativ - ich denke mal, der PC-Speicher wird größer sein. Da beim Speichern in eine Datei schonmal recht große OS-bedingte Verzögerungen auftreten können, sehe ich die Gefahr des Overrun beim Ringspeicher des Senders als deutlich größer an, als dass die Queue "überlaufen" würde.
Das Auf- und Zugemache der Datei ist sicher in beiden Fällen kein Problem, da man die Datei beim Prozessstart erstellen / öffnen und dann auf die Dateireferenz arbeiten würde. Ein PC-Absturz wäre hier auch nicht problematisch.
Die Zeitverzögerung durch das Senden der Daten an die Consumerschleife ist in bezug auf die Zeiten, die das Speichern der Daten dauert so marginal, dass sie vernachlässigbar ist.

Die Frage ist im Grunde, von welchen Datenfluten wir hier reden. Werden ein paar tausend byte pro Sekunde gesendet, kann man sich die Zweischleiferei sicher sparen - reden wir aber von Daten im ms-Bereich, würde ich den Queue-Puffer schon dazwischennehmen. Im übrigen gibt es auch TCP-Sendesysteme, die ihre TCP-Verbindung abbauen, wenn sie ihre Daten nicht loswerden - dann hättest du ein noch größeres Problem. Schon deshalb sollte das Auslesen der Schnittstelle mit hoher Priorität parallel erfolgen.


Gruß, Marko

Hallo Marko,

Du schreibst:

"... Im übrigen gibt es auch TCP-Sendesysteme, die ihre TCP-Verbindung abbauen, wenn sie ihre Daten nicht loswerden - dann hättest du ein noch größeres Problem. Schon deshalb sollte das Auslesen der Schnittstelle mit hoher Priorität parallel erfolgen. ..."

Muss ich mir das so vorstellen - das Echtzeitsystem hat einen Block - Sende Daten und dieser Block hat ein Timeout und wenn das Timeout erfolgt, weil Daten nicht losgeworden, dann wird Datenpaket gelöscht?

Manche Leute stehen auf dem Schlauch - warum? Manchmal muss man weit zum Hahn rennen, um das Wasser im Schlauch abzustellen. Man kann sich aber auch auf den Schlauch stellen und wenn der flexibel ist, dann kann man so den Massenstrom unterbrechen. Darum stehe ich manchmal auf dem Schlauch.

Hallo Hasenfuss,

Bei einer TCP-Verbindung "weiß" der Sender, ob seine Nachricht beim Empfänger angekommen ist. Ist dies nicht der Fall, muss er ja irgendwas machen. Wenn der Puffer des Empfängers voll ist, nimmt er sozusagen keine neuen Datenpakete mehr an. In diesem Fall kann es sein, dass der Sender die Verbindung abbaut und darauf wartet, dass sich der Empfänger neu mit ihm verbindet. Somit ist dann auch das Datenpaket verloren, wenn der Sender es nicht vorhält und bei einer neu erstellten Verbindung wieder sendet.

Nachtrag:

Quelle: http://de.wiktionary.org

auf dem Schlauch stehen (Deutsch)
Redewendung


Bedeutungen:
[1] einen Sachverhalt nur langsam erfassen, begriffsstutzig sein

Synonyme:
[1] ein Brett vor dem Kopf haben, eine lange Leitung haben, schwer von Begriff sein

Beispiele:
[1] Du stehst wohl etwas auf dem Schlauch.




Über Wasserhähne habe ich fast nichts gefunden.




Gruß, Marko