Idee für Modder - Emule 60% schneller mit PAQ statt Lzip
 

Wenn Emule Dateien sendet, benutzt er dafür die Online-Kompression Lzip, das basiert auf dem Packer GZIP.

Laut: Summary and conclusions packt der neueste Open Source Packer PAQ aber ca. 60% besser als GZIP und sogar noch 26% besser als RAR und 23% besser als 7z!
Sofern man mit Emule normale CD-Images austauscht und nicht nur bereits komprimierte Filme müssten die sich ja auch fast erreichen lassen.

[FONT=Tahoma]Kann man da nicht einfach innerhalb eines Mods die Online-Kompression austauschen? Also so das Zlib nur noch für offizielle Emules zum Einsatz kommt, und die Mods untereinander aber nur noch PAQ: The PAQ Data Compression Programs

Also so ähnlich wie Webcache! Man kann es benutzen, muss aber nicht! Etwa rechenlastiger ist es ja auch, wobei das ist ja relativ, auf meinem Pentium-M @2,5Ghz packt PAQ z.B noch ca. mit 20KB/s wenn Emule noch läuft, und mit DSL-1000 kann ich eh nicht schneller senden als maximal 16KB/s, also allein da würde das doch schon Sinn machen. Die Binary von PAQ ist übrigens nur 105KB gross!

Sofern ein Mod nicht permanent in Echtzeit packt, sondern die PAQ komprimierten Daten teils nur temporär ablegt, wäre die CPU-Auslastung ja auch nicht höher als wie jetzt schon! :-)

Hmmm... An diesen Kompressionsraten habe ich Zweifel. Abgesehen davon habe ich einen Duron 950 und wie die meisten mit besseren Anbindungen setze ich Mods ein. Der Rechner packt also mit ca. 8 kb/s. Und wann soll denn "im Voraus" gepackt werden, wenn der Rechner läuft, das Muli wegen des Ozonloches aber nicht? Gepackte Dateien müssen auch ausgepackt werden, das kostet auch Rechenleistung und zwar nicht zu knapp. Kurz: Vergiß es...

Ich werde mich aber dennoch mal belesen, vielleicht kann man die Dateien ja in diesem Packformat releasen. Das würde allerdings voraussetzen, daß die gänigen Packprogramme es auch unterstützen.

Mit freundlichen Grüßen
aalerich

Nachtrag: Ich verstehe den Autoren der Seite so, daß es sich um einen "Experimentalpacker" handelt, ein Programm, das ohne Rücksicht auf Rechenleistung und Nutzerfreundlichkeit nur und ausschließlich auf maximale Kompression Wert legt. Also auch nichts zum Vorabkomprimieren neuer Releases.

Ich stell mir das so vor, wenn der Muli läuft, fängt er automatisch an, Teile die angefragt werden, zu packen und temporär zu speichern. Egal wie lange oder oft Emule läuft, mit jedem Emulestart wächst diese Datei ja dann. Natürlich sollte es eine Obergrenze dafür geben, vielleicht ca. 1GB. Jedenfalls sollte sie irgendwann groß genug sein um seine Clienten damit auch bedienen zu können!

Was die Rechenleistung angeht, die ist doch völlig relativ, täglich werden ältere Rechner gegen neue ausgetauscht und in einem Jahr gehört praktisch jeder PC von heute schon wieder zum alten Eisen, man sollte da einfach mal in die Zukunft setzen und der Community vertrauen! Wenn man selbst wirklich nur einen alten Duron oder Celeron hat, schaltet man das Feature eben einfach ab, ich hätte jedenfalls aber kein Problem damit, für andere meine PC Leistung zu nutzen! Im Gegenzug krieg ich ja auch Power PAQ gepackte Teile zurück!

Die dadurch gesparte Upload Zeit, bleibt ja auch im Netz für alle anderen! Vom Webcache profitieren indirekt ja auch alle anderen, die es nicht nutzen! :-)

Nur Releases fertig vorzupacken halt ich für Verschwendung, dann würde die meiste Zeit, nämlich die in der Emule arbeitet völlig ungenutzt bleiben und man müsste Stunden opfern nur um mal eine CD zu packen und später wieder zu entpacken, die Disziplin hat die Community auch nicht für alle anderen alles Paq zu packen. Wenn der PC permanent Teile packt und ankommende in Echtzeit entpackt, ist das doch viel besser.

...irgendwie widerspricht sich da gerade was...
...meinst du nicht auch Ashert...?! :shock:


greetz Sorrow :dance

Nö es ist doch ein Unterschied ob ich jedes File einzeln selber packen muss, über Stunden und Tage oder ob Emule das für alle Files immer automatisch macht sobald er läuft!

Genau aus dem Grund hat man früher ja auch Zlib eingebaut, weil klar war das nicht jeder seine Files mit Zip packt, sonst hätte man sich das auch sparen können. Das kann man vom einzelnen vorbildlichen Releaser erwarten, aber nicht von 20Mio Usern aus aller Welt! Wir brauchen da einfach einen Knopf: "Real-Time PAQ-Compression on/off" mit einem zusätzlichen Schieberegler: "100MB-1GB PAQ Temp" wenn die nämlich voll sind, brauch auch nichts mehr gepackt zu werden, ausser natürlich neuere Teile die man gerade selber saugt um alte zu ersetzen, ähnlich wie der Windows-Papierkorb ja auch funktioniert.

...ich meinte eigentlich die verteilung der rechenlast... :yes:

...ob nun der esel packt und entpackt (was ja schliesslich auch gemacht werden muss) oder der user selbst, ist doch im nachhinein "gehoppst wie gesprungen", oder?!... :neutral:


greetz Sorrow :dance

Wenn der User das macht kostet das vieeeeel Zeit, wenn Emule das im Hintergrund macht, kriegt man das hingegen garnicht mit. Die Masse der CD Release liegt im ed2k nicht komprimiert vor. Ich hab keine Lust im Nachhinein irgendwas selber zu machen bzw. 10 Stunden zu warten bis die PAQ Decompression abgeschlossen ist.
Wenn Emule 3 Tage an einer CD saugt, dann kann er die Zeit doch auch sinnvoll dafür nutzen.

...nun...
...ich sehe, dass wir aneinander "vorbeireden", daher beende ich die diskussion meinerseits... :-?
...schade...lass aber ruhig nochmal den post von aalerich auf dich wirken (wir meinen so cirka dasselbe...)

...bis zum nächsten thread... :chuckle


greetz Sorrow :dance

Ihr geht halt immernoch von einem Duron 950Mhz aus (etwas was man nichtmal mehr kaufen kann) und nicht davon das die durchschnittliche PC-Leistung doch täglich wächst. Jeder der heute schon ein intel Dual Core leicht auf 3Ghz übertaktet hat, für den spielt weder die Echtzeitkomprimmierung eine Rolle noch gleichzeitiges entpacken! :neutral:

Da das entpacken eigener Files vorrang hat, müsste natürlich immer nur dann gepackt werden, wenn gerade nichts entpackt werden muss. Deswegen meint ich doch, da würde vielleicht ein eigener PAQ-Temp helfen, dann wäre es völlig egal, wie wenig Rechenleistung man zum packen übrig hat. Der Temp zweigt abzüglich der CPU-Leistung die man stetig fürs entpacken brauch von der übrigen immer noch etwas ab, spätenstens wenn die Files komplementiert sind und Emule immernoch läuft. So sammelt der Bit für Bit, Byte für Byte und mit der Zeit hätte auch der langsamste Rechner ein stattliches Reservoir an PAQ-Daten!

Beispiel: Mein Emule läuft derzeit mit 12KB/s Upload, obwohl ich nichts selber garnichts angefragt habe, einfach weil es mich nicht stört und der Rest zum surfen voll ausreicht!

Die CPU-Auslastung liegt dabei derzeit unter 1%! Genau jetzt könnte also mein Emule eigentlich anfangen, die Daten die ich uploade, umzuwandeln, in einem PAQ-Temp zwischenzuspeichern und als solche dann auch zu senden!

Das passiert aber nicht! Fazit:
Niemand will meine CPU-Leistung für mehr Speed!
Dabei müssten die Daten doch nur noch entpackt werden bzw. von wohl mindestens ca. 20% aller Emuleclienten die gerade ohne Download als reine Anbieter auftreten! Wie kann man dermaßen geschenkte Resourcen vergeuden? http://www.wdisneyw.com/forums/image...s2004/sand.gif

Schon mal überlegt, dass nicht jeder däumchendrehend vor einer 3 GHz-Maschine sitzt und seinem eMule beim werkeln zuschaut? Manche von uns benutzen ihre Rechner tatsächlich sogar für andere Dinge und sind sehr froh dass eMule nicht allzuviel CPU-Leistung verbraucht.
So wie du argumentierst dass in einem Jahr genug Rechneleistung verfügbar sein wird damit Online-PAQ nutzbar wird könntest du auch argumentieren dass in einem Jahr jeder so schnelle Internetverbindungen hat so dass wir alles auf's Packen verzichten können. :P

Achja, wenn du eine 3 GHz-CPU zu verschenken hast, nur her damit. ;)

weißt Du eigentlich, daß Releaser die Komprimierung ganz ausschalten ? Weil selbst auf einem schnellen Rechner kommt emule mit dem komprimieren nicht mehr nach, wenn Du mal mit mehr als 1 GBit hochlädst.

Du meinst Mbit nicht Gbit?

99.999 aller Uploader sind doch auch keine Releaser als mehr nur Clienten bzw. re-relaser die nur mit DSL1000 = max. 128Kbit uploaden bis zu DSL6000 = max. 512Kbit, um die geht es doch, die sind doch die wahren Verteiler, die Masse machts!

Selbst als DSL6000 Uploader würde mein Rechner wohl kaum 5% ausgelastet, wenn er mit DSL1000 ja noch unter 1% liegt!

sowas muss überhaupt nicht viel Geld kosten, das kann man sich auch selber basteln, guck mal hier:
http://www.forumdeluxx.de/forum/showthread.php?t=209283

nächstes Jahr gehört sowas von der Leistung längst zum guten Ton, man sollte doch wenigstens denen die sie heute schon haben, den Paq-Knopf anbieten! Natürlich mit einem Warnhinweis "Achtung CPU-Auslastung 100%"

Speziell Leute die es wirklich nur auf releasen angelegt haben, wäre das doch ein schicker Service, die wollen doch auch nur maximale Verbreitung innerhalb kürsester Zeit, dafür würden sie die CPU-Resourcen doch bestimmt gerne opfern!

btw. PAQ bietet ja eigentlich auch 8 Levels und nicht nur die default Einstellung -4.
Level -1 (21MB Ram) bis Level -8 (1800MB Ram)

Selbst in Level 1, packt es noch deutlich besser als Rar oder Zip!
Auf meinem 2,5Ghz PenitumM mit 117,5Kbyte/s ,das ist schneller als man mit DSL1000 überhaupt saugen kann, da bräuchte man nichtmal mehr ein Temp zum zwischenspeichern für!

Ein Mame Rom, z.B Gunbird2:

ist entpackt: 61,5 MB gross
mit 7zip normal Zip gepackt: 20,8MB gross
als RAR: 18,9MB gross
und selbst mit PAQ nur im low Level-1 noch deutlich kleiner: 16,6MB gross!
Das kostete weder Zeit noch würde es den maximal möglichen Upload der mit DSL6000 möglich ist ausbremsen, der liegt ja auch nur bei 512KBit/8= 64Kbyte!

Man sollte den Leuten das einfach mal anbieten, einschließlich der Stufen!
Beim normalen Hard und Quellenlimit in Emule muss man ja auch immer erst ausbooten, was überhaupt geht! Das hängt immer vom Betriebssystem ab, vom Rechner und anderen Dingen. Da gibts auch keine automatische Optimallösung für alle!

ich nehme mal an du hast das ganze unter der bedingung durchgeführt, dass du nur ein file gepackt hast. jetzt muss aber emule mehrere dateien gleichzeitig packen. das ist immer erst block lesen -> komprimieren -> senden......mal vereinfacht dargestellt.....jetzt kannst du aber ja mal schauen wieviele uploads du hast und wieviele blöcke da pro sek durch die leitung machen....das iss bei dicken leitungen pro sek nicht nur einer pro client.....und dann geht die cpu last schnell mal in die höhe....
ich mein sicherlich ist es schön nen komprimierungssystem zu haben was besser als alles je dagewesene komprimiert....nur wenn es dann auf die kosten meiner cpu-last geht und ich dann meinen rechner net mehr ordentlich bedienen kann dann muss ich sagen....nein danke!
cya
JvA

Mich würde interessieren wie groß die Datei mit Level-8 ist, wenn du das mal überprüfen könntest. Wenns geht nennst du bitte noch die Zeit, die alle Programme gebraucht haben und evtl. ein prozentuales Entergebnis das sich aus Komprimierung und der benötigten Zeit ergibt :mrgreen:

Ich könnte mir das ganze experimentell schon vorstellen, schaltbar selbstnatürlich.

mfg,
LuZiFeR

(Daher habe ich mich mit Level 5 begnügt, tatsächlich benutzt wurden knapp 200 mb.)


Ich habe das Ding mal kurz einem Vergleich unterzogen:

Testdatei ist eine mpg von ungepackt 3 805 kb.

paq8 auf Level 5:

rund 10 Minuten 97% Prozessorlast Ergebnis: 3 234 kb

paq8 auf Level 1:

rund 2 Minuten 97% Prozessorlast Ergebnis: 3 254 kb

Winrar auf Maximum:

rund 30 Sekunden 97% Prozessorlast Ergebnis: 3 296 kb

Powerarchiver zip auf maximal:

ein paar Sekunden 97% Prozessorlast Ergebnis: 3 292 kb

Powerarchiver 7zip maximal:

keine 10 Sekunden 97% Prozessorlast Ergebnis: 3 293 kb

Powerarchiver CAB auf LZX (Maximum):

ca. 10 Sekunden 97% Prozessorlast Ergebnis: 3 285 kb

Powerarchiver LHA auf Maximum (Frozen 6):

1 Sekunde 97% Prozessorlast Ergebnis: 3 805 kb

Powerarchiver BH auf Maximum:

2 Sekunden 97% Prozessorlast Ergebnis: 3 300 kb

Powerarchiver TAR als GZIPTar (beste Komprimierung der drei angebotenen TAR-Varianten)

1 Sekunde 97% Prozessorlast Ergebnis: 3 308 kb.

Mit freundlichen Grüßen
aalerich

Danke für deine unermüdlichen Tests, aalerich. Die Zahlen sprechen für sich, finde ich.

jo auf jeden fall sprechen die zahlen für sich.....ich mein bei gleicher komp-größe brauch das teil wesentlich (!!!!) länger....und ich glaube das will keiner!
thx aalerich
cya
JvA

Man muss Multimediadaten komprimieren, und keine mpg, die ist ja per Definition schon selber komprimiert, da kann nichts gescheites bei rauskommen, genau wie mit MP3, sowas wird in der Regel nicht nochmal gepackt!

Ich hab hier mal testhalber den "AlienShooter2 - Teaser - XviD High.avi" gepackt, da passierte auch nichts, weder mit 7z noch bh oder GZIPTar, es bleibt immer irgendwas zwischen 87 und 88MB.

Wenn man wissen will was ein Packer leistet, muss man schon die ganze ISO einer DVD packen, eben das was im Emule ja auch verteilt wird! Da sind dann zwar auch mpg. Daten mit drin, aber vorallem auch Gigabyte an Programmdaten, und um die geht es ja, die machen die Masse der getauschten Daten aus!

Und da zählt dann auch nur noch der prozentuale Packvorteil und nicht die Zeit fürs packen! Die müsste ja wie gesagt, nur EIN EINZIGES mal erbracht werden, und in einem Temp zwischen gespeichert werden. z.B jeder Emule packt z.B genau 20 MB am Tag oder von mir aus auch nur 1 MB in PAQ um, die dann dauerhaft im Temp liegen. So sammelt sich mit der Zeit auch ein stattliches Reservoir an hochkomprimierten Daten an, die dann kein PC mehr belasten!

Sind MPEG-Datein etwa keine Multimediadaten? Wäre mir neu.

War umseitig nicht deine Idee den Packer für eMule's Online-Kompression zu wechseln? Damit ist deine Erklärung hinfällig, denn eMule packt jeden angeforderten Block wenn er verschickt wird, nicht eine ganze Datei im Vorfeld - Online-Kompression eben. Dabei ist der Zeit- / CPU-Faktor ein sehr wichtiger. Ein Iso-Image einer ganzen DVD zu komprimieren ist Sache des Releasers.

Für ein paar Prozent mehr Kompression alle gesharten Dateien doppelt auf der Platte zu haben, wie du nun vorschlägst, halte ich für unsinnig, so ein "stattliches Reservoir" wird auf Dauer ziemlich teuer.

Ich meine immernoch die Online-Kompression, nur die muss ja nicht 24h am Tag laufen, das sollte der User frei einstellen dürfen, wie lange die mitlaufen soll!

Den Paq-Temp müsste man natürlich auch begrenzen dürfen, das der freiwillig wächst, könnte man ja über ein Rating klären, ähnlich wie in edonkey. Download max. mal 5 vom Upload, wer einen zu kleinen Paq-Temp einstellt für nur ein paar winzige Datei-Teile, der kriegt auch nichts, weil die ja dann auch jeder irgendwann mal hat!

Kurz: Emule brauch nur 2 Einstellungen:
1. wieviel Stunden soll der Paq-Onliner Packer mitlaufen
2. wieviel Paq-komprimierte Daten will ich in einem extra Temp Ordner speichern!

wer damit garnichts anfangen kann, stellt halt beide Werte auf 0! Wenn der Temp irgendwann die vorgegebene Größe erreicht hat, ersetzt er automatisch ältere Dateiteile durch neuerer.

Ich würde jedenfalls für mich mindestens einstellen. 1 GB Paq-Temp und mindestens 12h Online Paq-Kompression, die Zeit in der man schläft, kann man die CPU eh nicht voll auslasten!

Das verhältnis von investierten (Kompressions-)Aufwand zur Dateigrösse steht allgemein gesprochen nicht in einem linearem, sondern exponentiellem Verhältnis zueinander.

Für eine Echtzeitkompression wie im Esel sind diese Superpacker eher CPU-Quäler ohne spürbarem Nutzen.

Packt die Dateien einfach vorher und released die dann so klein wie möglich!

also da kann ich nur recht geben, und das wird doch auch schon gut genug gemacht!!!
da zieht man sich ein rar mit 3 GB, in diesem rar sind dann 80 andere archive (*.r01), wenn man diese teilarchive dann entpackt kommt ein dvd-image mit knapp 4 GB raus. WAS WILL MAN MEHR?
das reicht doch schon wenn das der releaser packt, bevor das file in umlauf geht.....

...und ausserdem haben die meisten user (ich jetzt auch!) einen schnellen dsl-anschluss, und dann machen die paar MB doch auch nichts aus.
(ihr müsst bedenken, das die durch das komprimieren verursachte cpu-last auch wieder mehr strom verbraucht....:yes:)

...ich finde man kann das so lassen wie es ist...

grüße
myth88