[eMule-Web]

[eMule-Web] (http://www.emule-web.de/board/)
-   eMule MOD - Development (http://www.emule-web.de/board/emule-mod-development/)
-   -   Idee für Modder - Emule 60% schneller mit PAQ statt Lzip (http://www.emule-web.de/board/10772-idee-fuer-modder-emule-60-a.html)

Pathfinder 27. May 2006 06:53

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

JvA 27. May 2006 10:29

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

Ashert 22. June 2006 11:15

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!

Pathfinder 22. June 2006 11:54

Zitat:

Man muss Multimediadaten komprimieren, und keine mpg
Sind MPEG-Datein etwa keine Multimediadaten? Wäre mir neu.

Zitat:

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

Ashert 22. June 2006 16:50

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!

Bandi 11. July 2006 10:09

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!

Myth88 11. July 2006 16:51

Zitat:

Zitat von Bandi
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


Alle Zeitangaben in WEZ +1. Es ist jetzt 07:27 Uhr.

Powered by vBulletin® Version 3.8.3 (Deutsch)
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
SEO by vBSEO ©2011, Crawlability, Inc.


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102