Online Kompression verbessern
 

Hallo

Ich würde gerne mal wissen, warum Emule intern eine Zlib Kompression verwendet und keine 7z(open source) die doch eindeutig allen anderen Zipformaten überlegen ist?

http://bloby.piranho.com/7z.png
The GIMP 1.2.4 for Windows after full installation (127 subfolders, 1304 files totaling 27,128,826 bytes)

was macht Zlib als Online-Kompression besser? In den meisten Fällen würde, ein Dateisegment mit 7z gepackt doch bestimmt kleiner ausfallen?

Die Features von 7z lesen sich jedenfalls so:

-Open architecture
-High compression ratio
-Strong AES-256 encryption
-Ability of using any compression, conversion or encryption method
-Supporting files with sizes up to 16000000000 GB
-Unicode file names
-Solid compressing
-Archive headers compressing
-High compression ratio
-Variable dictionary size (up to 4 GB)
-Compressing speed: about 1 MB/s on 2 GHz CPU
-Decompressing speed: about 10-20 MB/s on 2 GHz CPU
-Small memory requirements for decompressing (depend from dictionary size)
-Small code size for decompressing: about 5 KB
-Supporting multi-threading and P4's hyper-threading

Das deklassiert Zlib doch in jeder Hinsicht? Das kann man zwar sicherlich nicht einfach rausnehmen, da ja auch die Abwärts-Kompatibilität gesichert sein muss, aber theoretisch könnten doch die Mods anfangen sich untereinander zu erkennen und sich gegenseitig mit einer höheren Kompression zu bedienen?

Was haltet ihr davon? Wo liegen die technischen Schwierigkeiten? Und wie könnte man diese lösen?

Wenn man die Packdichte nur um 10% verbessern könnte, wäre es doch dasselbe als wenn man 10% an Geschwindigkeit gewonnen hätte bei herkömmlicher Kompression! :D

Ash,
sag mal willst Du es nicht kapieren ? Du bist auf dem offiziellen Board von den Admins gelöscht worden, weil dies Thema nichts mit emule zu tun hat und Du beharrlich nichts die Funktionsweise von emule verstehen willst.

Wie bereits dort erwähnt ist das von Dir vorgeschlagene Komprimierungsverfahren nur bei größeren Dateien sinnvoll. Da emule aber lediglich 180kb-Blöcke komprimiert ist das angewandte Verfahren bereits gut genug.

Wenn Du Dateien netzwerkschonend, hochkomprimiert unters Volk bringen willst, dann stell Deine Dateien mit 7z komprimiert ins Netz! Dein Vorschlag hat nämlich rein gar nichts mit emule zu tun.

Ich hoffe Du siehst Deinen Fehler endlich ein und wanderst nicht von Board zu Board um Deine Ansichtsweisen unters Volk zu bringen.

Selbst 180kbyte Dateien werden doch von 7z in der Regel deutlich besser gepackt.

Ich will nichts unters Volk bringen sondern nur was lernen.

1. Zum Beispiel der Config Ordner aus Emule 30a, 15 Dateien sind da bei mir drin, .mets .dats und eine ini Datei, insgesammt 115Kbye! Als 7z dann aber nur 28,3kbyte und mit Zip 49,8kbyte gross!

Man kann also auch in dieser extremen winzigen Blockgrösse noch erstaunlich Ergebnisse erzielen, von über 40% Gewinn! Wo ist denn das Problem?

2. Wie kommt diese 180kbyte Schranke überhaupt zustande, von was wird sie bestimmt, warum kann man diese nicht auf z.B das zehnfache erhöhen, auf 1.75Mbyte?

und wie gesagt 7z ist doch auch bei 180kbyte Blockgrössen, eindeutig überlegen, oder nicht?

3. und warum werde ich für meine Fragen immer gleich angefeindet? :cry:

ps. Das die Leute ihre CD-Images gleich 7z komprimieren ist doch unrealistisch, die meisten nehmen diese doch garnicht an, Top Releases wie sie auf den Eselseiten gesammelt werden, kommen doch nur brenn fertig als bin oder iso mit der cue dazu. völlig ungepackt. :|

zu 1. Es geht halt nicht um config files oder sonstiges. Welche Größe die haben ist schlicht weg egal
zu 2. Bevor emule das erste Packet losschickt muß es erst mal komprimieren. Bei 1,75 MB würde es einfach zu lang dauern.
zu 3. Weil man es Dir wirklich ziemlich ausführlich erklärt hat, Du aber zu beharrlich bist.

Ich würde an Deiner Stelle diese Diskussion in Releaser-Foren führen. Beweg doch diese dazu 7z zu benutzen.

Hey, da habe ich etwas verpasst. Aber so wie ich das verstehe, geht es doch
darum, ein besseres Kompressionsformat zu nutzen. Und das würde ich begrüssen.
Das Bessere war schon immer der Feind des Guten.
Entschuldige Xman, aber ich finde, die überreagierst etwas.
Das sollte doch ein Vorschlag sein und so etwas ist doch bei Verbesserungsvorschlägen
eindeutig hier am besten angebracht. Wenn die Fakten für eine bessere
Sache sprechen, so sollte sie auch dementsprechend ausdiskutiert werden.

Und in meinen Augen und Verständniss gehört dieses Thema sehr wohl zu Emule.

Warum werden denn die Mod´s usw gepackt und warum gibt es so viele
Fragen bezüglich : bekomme beim Entpacken nur TXT Files oder gar nichts.
WARUM : weil auf ein neues Kompressionsformat gewechselt wurde ohne
das die meisten davon wussten.

Ich persönlich würde es begrüssen, statt 50 Min. nur noch 45 Min. an einem
Chunk zu nuckeln.

Oder soll ich dir von mir gebrachte Beispiele bringen, wo ich Fragen an die
Modder gestellt habe und keine Antworten bekommen habe. Denn die
wichtigen Dinge wurden erst ab den 0.30 Versionen herausgebracht.
Ein Beispiel ist die sichere Erkennung der Clients. Wieviele
Unknown Clients gibt es in den 0.29 Versionen und wieviele in den 0.30.
Nämlich ab 0.30 keine

Du hast mir auch in einem Thread so eine Frage beantwortet.

Nein Danke, jeder verschiebt mich nur in ein anderes Forum, mit dem Hinweis, das es nur
1. egal ist
2. erklärt ist
3. ich nichts verstanden hab

ein 2Mbyte Datei mit 7z packen dauert auf meinem 1,8ghz AMD, 3sec. Im Prinzip könnte der Rechner immer schneller vorpacken als er maximal mit DSL senden könnte?

Zu 90% lassen sich auch alle Dateien in jeder Grösse mit 7z besser packen, nicht nur conf. Dateien etc. das war doch nur Beispiel, naja egal...

blomy,
ich reagierte so, da dieses Thema auf dem offiziellen Board bis zum Exidus durchdiskutiert wurde. ;-)

Du darfst 3 Faktoren nicht vergessen:
1. Lohnt sich der Aufwand von mehr Rechenleistung zu Kompression in der Praxis wirklich ? (wir haben alle zu wenig Ahnung von den emule-internas um das zu beurteilen)
2. Es muß abwärtskompatibel sein!
3. Das Zip-Format ist sozusagen "freeware". Es kann ohne Linzengebühren verwendet werden. Andere Formate kosten richtig viel Kohle.

Xman
1. auf dem offiziellen Board habe ich mich unter 3 verschiedenen E-Mail Adressen
angemeldet und nie eine Freischaltung bekommen. Also irrelevant. Wir sind hier !
2. Das bischen Rechenleistung ist bei jeder Gurke vorhanden.
3. mit der Ahnung hast du Recht, trotzdem ein sehr interessantes Thema.
4. zu 2 schon wieder hast Recht
5. zu 3 du nervst, hast schon wieder Recht :D

Trotzdem bin ich der Meinung und ! Überzeugung, das Ash ein wichtiges
Thema angesprochen hat.

Und es geht im allgemeinen wieder unter, wenn es um grundsätzliche
Probleme geht. Das nervt.

Wer sonst als wir, kann die Modder dazu bringen, etwas zu verbessern.

1. Ja, die Kompression parallel zu Rechenleistung ist ein Witz, maximal 4,2% auf einem 2500+ AMD mit 16kbyte/s Upload DSL Speed. (Es muss ja nicht schneller gepackt werden als er sendet)

2. Abwärtkompatibel ist Zlib, den Code könnte man doch für alte Clients noch solange drin lassen bis sie fast verschwunden sind, nur alle neueren Clients tauschen sich mit 7z aus.

3. 7z(open source) auch :roll:

Ash, so wie du das schreibst, ist es genau eine Funktion die vorwärts orientiert ist.
Sprich also auch abwärtskompatibel.

ok, das wußt ich nicht, hier spricht der Puntk für Dich.

So abwärtskompatibel wie Windows95 mit Dos, die alten Routinen bleiben einfach noch eine Weile drin.
Erst später nimmt man sie raus.

Emule ist doch faktisch abwärtskompatibel durch Zlib! 7z käme nur dazu, für alle Clients die es auch unterstützen. Das dauert natürlich ne Weile bis die in der Mehrheit sind und die Dinosaurier tot! :roll:

Ash, und was machen wir jetzt, um den Moddern das neue
Kompressionsverfahren schmackhaft zu machen ?

die kriegen ein keks und wenns drin ist auch zwei oder wir gehen protestieren http://www.mysmilie.de/smilies/schilder/img/003.gif ich weiss nur noch nicht wo :lol:

Ok hier ist einer
http://www.8ung.at/blomy/party/keks.jpg

Re: Online Kompression verbessern
 

Ein Dankeschön für deinen Tipp

Ich bin kein Emule Programierer, dafür gelegendlich ein Datei Releaser. 7z kannte ich bisher noch nicht...hab es also gleich mal getestet.

Bei einer 227 MB großen DivX AVI schaft

Winzip 8.1 = 222 MB
Winrar 3.0 = 221 MB
7Z = 219 MB

(alle drei Packer wurden auf Max Kompression eingestellt)

Re: Online Kompression verbessern
 

Es gibt auch noch ein, Uharc Packer v0.4 mit Gui der scheint auch ziemlich gut zu sein. :roll:

he leute das ist wirklich eine diskusion wert

macht weiter

mir währe lieber das die von euch genanten Pakete (10 * 180KB = 1,75MB) etwas verkleinert werden so auf ungefähr (4 * 180KB = 720KB) oder noch besser währe das mit den gegebenen verbindungsgeschwindigkeiten wariabel zu berechnen z.B. bei 56K nur (1 * 180KB = 180KB) und oder 128K (4 * 180KB = 720KB) oder und bei 768 [oder schneller] (10 * 180KB = 1800KB) dan wüden die Wartezeiten "vor allen"am anfang nicht so stark vareiren.

übrigens ich hab nicht den hauch einer ahnung was Programmierung oder Komprimierung angeht ich hab jetzt einfach nur meine Ideen ins Spiel gebracht. :mrgreen:

ciao Tonixic

Zu Ashs Vorschlag: Die Idee fände ich gut, mehr Kompression = mehr DL in der gleichen Zeit.
Die Kompression als zusätzliches Feature einzubauen (für Clients die das können) ist denke ich auch ok, es muß sich halt nur mal ein Modder dazu entschliessen, die zLib (normale Zip Kompression) geht ja nicht verloren, die kann 7z ja auch.
--> Verlieren kann man meiner Meinung nach nichts außer am Anfang einer Session ein paar Packets um das Kompressionsformat festzulegen (ala: ich biete dir an 7z zip oder unkomprimiert, wähle dein Schicksal!)

Zu Ashs weiterer Idee: man kann IMHO schlecht On the Fly komprimieren, da die endgültige Datei (das komprimierte Ding) erst nach der Komprimierung feststeht, also nix mit wir komprimieren so schnell wie wir senden.. wir können erst senden, wenn alles fertig gepackt ist.

Sourcen gibts bei SourceForge.

Ein kurzes googlen nach Vergleichstest sagt mir: 7z packt im schnitt um 10% besser als Winzip (Textdokumente deutlich besser, aber wer tauscht .txt?), ist aber um den Factor 8 langsamer als zip.

Allerdings sollte man bedenken das es mittlerweile ne 3.09 beta gibt und die womöglich etwas schneller ist als die alte.

edit: ab beta 3 unterstützt er auch HT, was vielleicht einigen zu neuen boosts verhilft..

Meine Meinung: kleine Blocks behalten und 7z wäre für mich völlig ok, wenn ich dann vor jedem verschickten Block 0.3 Secs warten muß.. na und? ich hab die CPU Power..

Nachlesen:
http://www.rojakpot.com/showarticle.aspx?artno=4&pgno=1
andere Tests:
http://compression.graphicon.ru/ybs/e&exes.htm
http://www.compression.ca/act-win.html

7-zip ist ja auch nur eine Gui für verschiedene Algorytmen "LZ+Huf" noch etwas besser wäre vielleicht eine "f+PPMII" Routine, wie sie der neue DURILCA Packer benutzt, auch wenn die noch etwas mehr CPU Power brauch.

Jedenfalls ist alles besser als wie der jetzige Algorithmus! Die Rechner von heute haben doch mit nix mehr ein Problem! Für die Kleckerei mit ein paar Prozentchen CPU Power pflegt man doch keine Dinosaurier.

Nur leider basteln ja alle nur drum rum, an echte Veränderungen im Kern denkt garkeiner! :roll:

etwas aktueller:
http://www.maximumcompression.com/