Idee für Modder

Ashert · 22. March 2006, 20:33

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!

aalerich · 22. March 2006, 20:55

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.

Ashert · 22. March 2006, 21:12

Zitat:

Zitat von aalerich

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

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.

**Sorrow** · 22. March 2006, 22:22

Zitat:

Zitat von Ashert

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 [...] 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[...]

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

greetz Sorrow

Ashert · 22. March 2006, 23:28

Zitat:

Zitat von Sorrow

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

greetz Sorrow

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.

**Sorrow** · 22. March 2006, 23:40

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

...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?!...

greetz Sorrow

Ashert · 22. March 2006, 23:58

Zitat:

Zitat von Sorrow

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

...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?!...

greetz Sorrow

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.

**Sorrow** · 23. March 2006, 00:10

...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...

greetz Sorrow

Ashert · 23. March 2006, 00:31

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!

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?

**Pathfinder** · 23. March 2006, 08:49

Zitat:

Die CPU-Auslastung liegt dabei derzeit unter 1%! [...] Niemand will meine CPU-Leistung für mehr Speed! [...] Wie kann man dermaßen geschenkte Resourcen vergeuden?

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.

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

**Xman** · 23. March 2006, 09:35

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.

Ashert · 23. March 2006, 11:26

Zitat:

Zitat von Xman

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!

Zitat:

Zitat von Pathfinder

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

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!

**JvA** · 25. May 2006, 10:28

Zitat:

Zitat von Ashert

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!

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

Luzifer · 25. May 2006, 12:20

Zitat:

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!

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

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

mfg,
LuZiFeR

aalerich · 26. May 2006, 17:42

Zitat:

Zitat von readme.txt

level: -0 = store, -1 -2 -3 = faster (uses 21, 28, 42 MB)
-4 -5 -6 -7 -8 = smaller (uses 120, 225, 450, 900, 1800 MB)

(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

Ähnliche Themen: Idee für Modder - Emule 60% schneller mit PAQ statt Lzip