OTR Key Decoder: Ungünstige Filezugriffe

[Bong]

Könntest du den Zusammenhang zu den Blockgrößen bitte mal näher erläutern?

[MKay]

Versuch mal den Decoder von Mr. S. Der soll fehlerfreier sein und funktioniert wunderbar ;)

Download:
http://www.otrdecoder.de.vu

[cb1]

Könntest du den Zusammenhang zu den Blockgrößen bitte mal näher erläutern?

Sicher. Im Prinzip kannst Du Dir einen Dateizugriff als Kommunikation vorstellen:

Client: Datei a öffnen
Filesystem: Datei a offen
C: Lese n Blocks / Bytes etc.
F: Übertrage n Blocks / Bytes
C: Lese n Blocks...
F: Übertrage n Blocks...
etc.

Beim Schreiben das gleiche Spiel (dann überträgt C an F). Nun bedingt diese Kommunikation zum einen einen gewissen Overhead (stell Dir vor, Du rufst einen Bekannten jedesmal an, wenn er Dir einen Satz eines Dokumentes per Mail zusenden soll.) und zum anderen einen gewissen Zeitverlust zum Verarbeiten (gleiches Beispiel, der Schreib-/Lesekopf muss jedesmall positioniert werden).

Wenn die Blockgrößen dabei zu klein sind, bremst das Verfahren den gesamten Vorgang. (Stell Dir vor, Du lässt Dir jedes Wort oder gar jeden Buchstaben einzeln per Mail zusenden!)

Im vorliegenden Fall scheint der OTR-Decoder dabei eine sehr kleine Blockgröße (meine Vermutung strebt gegen 1) zu verwenden. Liegt die zu decodierende Datei auf meinem NAS, ist das Decodieren unglaublich langsam. Alle anderen Zugriffe auf dieselben Files auf dem NAS (funktioniert wie eine Dateifreigabe per SMB bei Windows), also Abspielen, Schneiden per VirtualDub u.ä., sind nicht spürbar langsamer als wie wenn das File auf einer lokalen Partition liegt.

Da der Overhead bei einem IP-Zugriff (ein NAS wird ja über das TCP/IP-Netzwerkprotokoll angesprochen) größer ist als ein Direktzugriff auf eine lokale Festplatte, macht sich das ganze stark bemerkbar...


Versuch mal den Decoder von Mr. S. Der soll fehlerfreier sein und funktioniert wunderbar ;)

Download:
http://www.otrdecoder.de.vu
Sieht gut aus (ein großes Lob an Mr. S!) und enthält interessante Informationen. Mit der STandardeinstellung ist es genauso schnell/langsam. Eine 60min Aufnahme benötigt in etwa die gleiche Zeit zum Decodieren. Aber es sind ja nun weitere EInstellungen möglich. Und ich habe folgende Info gefunden:


Speicherpuffer
Das Codierungsverfahren ist ziemlich bescheuert. Neben einer anständigen Codierung werden die Fragmente nach einem bestimmten Muster durcheinandergewürfelt. Um so eine Datei zu decodieren muss also das Programm wild auf der Festplatte hin- und herspringen um die Blöcke einzulesen und zu dekodieren. Der Speicher soll dazu dienen dieses springen zu vermindern, da dies ungesund ist. Dabei werden mehere Fragmente hintereinander in den Arbeitsspeicher kopiert und erst dort durch springen sortiert. Der Speicher ist übrigens noch nicht ganz komplett implementiert und daher ausgeschaltet!

Damit wäre die Ursache m.E. erkannt. Wildes Umherspringen im File bei wohl kleiner Blockgröße. Schade, dass der Speicherpuffer noch ausgeschaltet ist. Oder in die andere Richtung: Wozu das würfeln, wenn bereits eine Codierung vorliegt?

[Mr. S]

Damit wäre die Ursache m.E. erkannt. Wildes Umherspringen im File bei wohl kleiner Blockgröße. Schade, dass der Speicherpuffer noch ausgeschaltet ist. Oder in die andere Richtung: Wozu das würfeln, wenn bereits eine Codierung vorliegt?
Was der Blödsinn soll, weiss ich bis heute nicht! Der Speicher ist ausgeschaltet, weil mir die Zeit zur Implementierung ansgegangen ist. Bis Mitte März habe ich leider keine Zeit irgendwas zu programieren. Danach werde ich mich mit dem neuen Decoder auseinandersetzen und meinen dementsprechend neu schreiben. Sollte die bescheuerte Blockverschiebung immernoch existieren werde ich früer dran denken den Speicherpuffer einzubauen.

[Bong]

Thx 4 Info. Dass es so krass ist bzw. im Netz so einen Unterschied macht hätte ich nicht vermutet.

[cb1]

Leider ist es so extrem, der Overhead überwiegt offensichtlich bei weitem.

Ich habe gestern mal getestet und - ungünstige Auswahl :rolleyes: - einen 3GB-Film in über 22 Stunden (!!!) dekodiert. Normale Filme mit etwa 1GB haben mit lokaler Platte keine 10min gedauert...

@Mr. S: Mein Lob für den Decoder!

[Eos]

Hi!

Wieso liest man wohl in der Anleitung, daß der Decoder auf Netzlaufwerken nicht funktioniert? NAS ist Netzwerk!

Sei froh, daß Du die Aufnahmen nicht versemmelt hast und einen Reset brauchst.

Eos

[cb1]

Wieso liest man wohl in der Anleitung, daß der Decoder auf Netzlaufwerken nicht funktioniert? NAS ist Netzwerk!

Der Ausdruck 'Netzlaufwerk' ist m.E. zu undifferenziert. Darunter ließen sich alle Arten von Netzwerklaufwerken wie SMB (NAS, NDAS, SAN), aber auch FTP- und WebDAV-Laufwerke subsumieren. Ich sehe auch aus Anwendungssoftware-Sicht keinen Unterschied zwischen einer lokalen und einer per SMB erreichbaren Partition, da dies gleichermaßen transparent identisch erscheint. Auf einem Wintel-System macht eine hardwarenahe Ansteuerung von Peripheriegeräten ja keinen großen Sinn, insofern frage ich nach einem stichhaltigen Argument.

BTW: In meiner Anleitung zum Decoder5 steht sichts zum Thema 'Netzlaufwerk'!?