Riesenringpuffer

  • Themenstarter Gelöschtes Mitglied 9001
  • Beginndatum
Diskutiere Riesenringpuffer im Allgemeine Java-Themen Bereich.
G

Gelöschtes Mitglied 9001

Die Betrachtung der Zeit spielt bei Algorithmen schon eine wesentliche Rolle. Ich möchte eben mich nur ungern verteidigen müssen, warum ich nicht MP3 oder einen stärkeren Rechner verwende und ob ich das Linux denn auch schlank genug konfiguriert hätte, denn das sind Dinge, die keine Antwort auf die Frage nach einem effizienten Algorithmus liefern. Die Fragen danach sind sicher legitim, aber ich denke, wenn ich das 1x beantwortet habe, ist es genug. Wenn die Antwort immer lauten würde: „Nimm einen stärkeren Rechner.“, dann bräuchten wir keine vernünftige Informatikausbildung mehr, weil die erstbeste Lösung, die irgendwie funktioniert, schon akzeptiert werden würde und die Performance soll dann die Hardware liefern. Dann könnte man auch sagen: warum brauchen Betriebssystem Swap-Speicher - offensichtlich ist der RAM zu klein, nimm einen größeren. Und dann bräuchte man das durchaus sehr interessante Thema Swapping-Methoden gar nicht mehr diskutieren - Problem vermeintlich gelöst. Es wäre der schon oft thematisierte (natürlich überzeichnete) Aspekt: was die Hardware-Ingenieure an Performance entwickeln, machen die Software-Ingenieure wieder zunichte. Aus diesem Grund gebe ich mich mit der Antwort: „kauf einen Rechner mit mehr RAM“ nicht zufrieden und finde es auch etwas befremdlich, dass eine solche Antwort in einem Programmiererforum kommt.
 
Zuletzt bearbeitet von einem Moderator:
U

user30

keine vernünftige Informatikausbildung mehr
Erstmal ist das ein Studium und zweitens bedarf es diesem sehr wohl, um von vornherein Dinge ausschließen zu können, die schlicht theoretisch und praktisch nicht möglich sind... Dazu zählt zB ein riesiger Buffer mit unsinnigen Daten auf einer dürftigen Hardware... Oder geht es dir darum, möglichst effizient Speicherkarten zu schrotten?
 
G

Gelöschtes Mitglied 9001

Erstmal ist das ein Studium
Ja, da hast Du recht.
und zweitens bedarf es diesem sehr wohl, um von vornherein Dinge ausschließen zu können, die schlicht theoretisch und praktisch nicht möglich sind...
Ich kann es nicht wissen, nur vermuten, dass Du möglicherweise zu der jüngeren Generation gehörst, die - ich sag es mal so - in einem Hardware-Schlaraffenland lebt, wo sich jeder noch so ineffiziente Algorithmus durch einen schnelleren Prozessor und mehr RAM „beheben“ läßt.
Das Auslagern von Daten aus dem RAM in einen langsameren, aber größeren Speicher gehört mit zu den Aufgaben eines jeden Betriebssystems. Erst damit wurde es möglich, dem Benutzer echtes/virtuelles Multitasking anzubieten, größere Datenmengen zu verarbeiten und und und. Und diese Thematik wurde in Fachbüchern behandelt, die erschienen sind, als die Hardware deutlich dürftiger war als ein heutiger Raspi.

Ich schrieb es schon: gängige Fieldrecorder (das sind Tonaufnahmegeräte) beschreiben SD-Karten zig-Gigabyteweise. In meinem gesuchten Fall geht es um einige wenige GB im worst case. Im best case wird die SD-Karte gar nicht angerührt. Es gab hier ein paar Vorschläge, die darauf abzielten, dass die Daten grundsätzlich auf der SD-Karte gespeichert werden sollen. Das wäre tatsächlich nicht so günstig.

mit unsinnigen Daten
Woher nimmst Du die Gewissheit, dass es sich hier um unsinnige Daten handelt?
 
G

Gelöschtes Mitglied 9001

So, meine lieben Freunde, ein Wort zum Schluß. Mein Anliegen war es, den Thread nah beim Thema Programmierung zu lassen. Es tut mir sehr leid, wenn sich dadurch jemand gekränkt gefühlt hat, das war ganz sicher nicht meine Absicht. Ich selbst empfand es als unangemessen, das Projekt als „scheiße“ bezeichnet zu sehen, mir vehement die Notwendigkeit abzusprechen, dass ich hochaufgelöste Audiodaten unkomprimiert brauche, und in Frage zu stellen, was sich hier bei mir durch Tests schon lange bewährt hat. Ich schrieb das ja mehrfach. Ich habe nicht nur bei diesem Thread beobachtet, dass Themenstarter gern von oben herab behandelt werden im Sinne von: lern du erstmal richtig programmieren, bevor du hier bei uns ankommst. Das ist nicht bei allen Postern so, aber doch bei einigen. Das so als Feedback.
Ich bedanke mich sehr für alle Programmier-Beiträge, die mir Impulse gegeben haben. Das ein oder andere fließt bestimmt mit ein.
Ich verabschiede mich jetzt aus diesem Forum. Macht's gut.
 
mihe7

mihe7

@Rajmund das darfst Du nicht so eng sehen. Das Forum ist einfach eine Mischung aus Stackoverflow und Stammtisch-Diskussionen :) Da wird sich auch über Alternativen unterhalten oder einfach ums Thema, weil es jemand interessant findet.

Inhaltlich ist die Sache ja scheinbar schnell erklärt: Du hast einen ankommenden, kontinuierlichen Datenstrom von etwa 2 MB/s und die Frage ist, wie sich das derart puffern lässt, dass der Client, der diese Daten abholt, auch mal eine halbe Stunde offline sein darf. Bislang bekannte Einschränkungen sind:

1. das RAM des Systems reicht nicht aus, um die Daten vollständig darin abzulegen
2. als Sekundärspeicher wird (billiger) Flashspeicher benutzt

Ich sehe 2. übrigens nicht unbedingt als Nachteil an. Genauso, wie man sich ein teureres System mit mehr RAM anschaffen kann, kann man auch alle heiligen Zeiten die SD-Karte ersetzen. Kassetten hielten auch nicht ewig :)

Müsste man das Medium nicht schonen, wäre mein erster Ansatz, das Zeug einfach auf die Karte zu schreiben und von dort wieder zu lesen. Hier ergibt sich dann das erste Problem:
Wenn der Abholthread nun plötzlich einen Datenblock auf die Karte schreiben muss oder einen Block löschen, braucht er etwas mehr Zeit.
Es können sich also beim Schreiben Schwankungen ergeben, so dass man einen Empfangspuffer im RAM vorschaltet, um diese auszugleichen. Sagen wir mal 10 MB, dann könnte man 5 Sekunden überbrücken.

Da der Client nicht zeitkritisch zu sein scheint, wäre das Problem auch schon gelöst, wäre da nicht noch die Sache mit der Lebensdauer der SD-Karte... Dabei geht es nicht ums Wear-Leveling, das ist Aufgabe der Treiber/Karte, sondern schlicht darum, die Zahl der Schreibzugriffe auf die Karte zu reduzieren.

Also wird ein weiterer Puffer benötigt. Der erfüllt seinen Zweck aber nur, so lange er nicht voll ist. Danach muss jede Operation auf der Karte ausgeführt werden.

Spätestens jetzt kommt auch der Client ins Spiel: wie schnell kann an den Client ausgeliefert werden? Wenn der Client die Daten ebenfalls nur mit max. 2 MB/s abruft, dann wird der Puffer niemals leerer und das System arbeitet, sobald der Puffer einmal voll ist, als ob der ursprüngliche Ansatz implementiert worden wäre (direkt auf Karte schreiben). Es könnte auch sein, dass der Client in unregelmäßigen Abständen Daten abruft, dann aber mit höchstmöglicher Datenrate. In dem Fall könnte es sinnvoll sein, die Daten ggf. bereits im RAM vorzuhalten werden (eine Art Sendepuffer). Das sind Dinge, die müsste man sich eben ansehen.

Das alles hat jetzt nichts mit der Umsetzung eines Ringbuffers zu tun (das sollte ja nun nicht das Problem sein), sind aber Überlegungen, die man m. E. anstellen muss.

EDIT: nu isser weg.
 
M

Meniskusschaden

Oh, da hat wohl jemand Probleme mit Meinungstoleranz. So kann es eben ausgehen, wenn man in jedem zweiten Posting seinen eigenen Thread torpediert. Andererseits vielleicht verständlich, wenn man den Anspruch hat, selbst zwar schon über den gesamten Problemkontext reden zu dürfen, anderen das aber nicht zugestehen möchte. Wenn man sich dann - wie die Fahrplananalogie nahelegt - noch in der Rolle des Arbeitgebers sieht, dem die Forenmitglieder zuarbeiten, wird man natürlich schnell von den Reaktionen eines offenen Diskussionsforums enttäuscht. Andere Meinungen können aber auch wirklich lästig sein. Da verdreht man dann schon mal gerne, wer hier eigentlich respektlos gepostet hat. Psychologisch äußerst interessant.

in einem Hardware-Schlaraffenland lebt, wo sich jeder noch so ineffiziente Algorithmus durch einen schnelleren Prozessor und mehr RAM „beheben“ läßt.
Wenn man aus prinzipiellen Gründen immer eine Softwarelösung vorzieht, ist das genauso schlecht, als wenn man aus Bequemlichkeit auf Optimierung verzichtet und lieber in Hardware investiert. So etwas ist doch immer einfach eine Abwägung der Verhältnismässigkeiten. Ideologie ist da fehl am Platz.
 
J

JustNobody

@mihe7 Also bei 2MBit/s stream ist es problematisch, wenn gleichzeitig gelesen und geschrieben werden muss, denn teilweise hat die Karte nur um 5MBit/s - also etwas knapp.

Aber es war von einer Verbesserung die Rede: und die erreicht man mit einem Ansatz wie z.B. dem von mir skizzierten und dann auch implementieren.
Oder habe ich da was vergessen/übersehen?

Und das wear Leveling kümmert sich bei allen Schreibzugriffen gut um die Problematik? Dann waren meine Sorgen diesbezüglich wohl falsch. Ich habe aber halt beim pi schon mehrere Karten gehämmert, so dass dies zumindest menschlich meine Sorgen erläutert (und ich arbeite fast nur mit Raspian) ....
 
mihe7

mihe7

Also bei 2MBit/s stream ist es problematisch, wenn gleichzeitig gelesen und geschrieben werden muss, denn teilweise hat die Karte nur um 5MBit/s - also etwas knapp.
S. #59 :)

Aber es war von einer Verbesserung die Rede: und die erreicht man mit einem Ansatz wie z.B. dem von mir skizzierten und dann auch implementieren.
Was meinst Du mit Verbesserung? Ich wollte Deinem Ansatz gar nicht widersprechen, sondern im Hinblick auf #124 mich der Problematik nochmals nähern, wobei deutlich werden sollte, dass es weit mehr Überlegungen/Probleme gibt, als eine (triviale) Implementierung eines Ringbuffers.

Und das wear Leveling kümmert sich bei allen Schreibzugriffen gut um die Problematik?
Das weiß ich nicht, davon muss ich ausgehen dürfen bzw. muss mich nicht interessieren; die Karte ist Verbrauchsmaterial. Wenn ich mal von 3000 Zyklen ohne Wear-Leveling ausgehe, dann könnte man eine 6 GB große Datei (~ 1 h der Audiodaten) 3000 x überschreiben. das wären 3000 Stunden oder 125 Tage. Mal davon ausgehend, dass das Ding 24 Stunden am Tag zu 100 % puffert, sollte es kein Problem darstellen, die Karte alle 1, 2 oder 3 Monate zu wechseln :)

Ich würde das Dateisystem noch mit noatime mounten und die Datei(en) in der gewünschten Größe einmal erstellen. Das hätte den Vorteil, dass das Dateisystem nicht mehr aktualisiert werden muss und hierfür keine Schreibzugriffe anfallen.
 
J

JustNobody

Ok, das mit #59 kann ich nachvollziehen. Aber wie gesagt: Bei einem pi traue ich der IO Leistung nicht wirklich ...

Bezüglich Verbesserung: Das war eine Aussage vom TE, die ich jetzt nicht nachgeschlagen habe. Aber ich erinnere mich an einen Post, in dem er seine Aufgabe so beschrieb, dass er die Situation auf jeden Fall verbessern solle. Und ich habe das von Dir auch nicht als Widerspruch gesehen sondern ich bin halt nur am überlegen, ob ich wichtige Punkte einfach übersehen habe. Und die Lösung kommt mir teilweise auch verkompliziert vor und ich bin halt immer noch unsicher, ob dies überhaupt so Sinn macht.

Dein Ansatz, da einfach komplett möglichst optimiert auf der Karte zu arbeiten ist eine gute Vereinfachung und die gefällt mir nun eigentlich immer besser (jetzt wo der TE weg ist, muss man ja auch nicht mehr seine ursprüngliche Anforderung so fest halten ... das Du böse bist, weil Du da ständig sowas bringst, obwohl er doch mehrfach .... *lol*)

Wobei ich halt auch das eigentliche Problem angehen würde und das ist die Netzverbindung. Wenn die WLAN Verbindung so problematisch ist, dann wäre evtl. ein kleiner WLAN Repeater interessant, der auch nicht mehr kosten würde als ein pi. Und dann hat man eine stabile Verbindung, die die 2Mbit/s relativ sicher transportiert.

Die Vermeidung der Schreibzugriffe beim Verzeichnis ist auch noch ein interessanter Punkt. Ebenso die Kalkulation bezüglich Haltbarkeit - das hätte ich eigentlich auch schon früher machen können, um diese bessere Bewertung zu bekommen - wobei ich da irgendwie noch nicht die Abstraktion hatte von FileSystem Blöcken und den Medien-Blöcken... und da Unsinniges optimieren wollte (Ja, Optimierung ist böse, vor allem ohne grundsätzliche Analyse ... q.e.d. würde ich sagen.)
 
Thema: 

Riesenringpuffer

Passende Stellenanzeigen aus deiner Region:
Anzeige

Neue Themen

Anzeige

Anzeige
Oben