[eMule-Web]

[eMule-Web] (http://www.emule-web.de/board/)
-   eMule für Neulinge - und auch alte Hasen (http://www.emule-web.de/board/emule-fuer-neulinge-und-auch/)
-   -   Zuverlässiger Trick um Emule zu beschleunigen (http://www.emule-web.de/board/13912-zuverlaessiger-trick-um-emule-zu.html)

Kabeljau 16. January 2009 18:53

Zuverlässiger Trick um Emule zu beschleunigen
 
Ich habe einen Trick entdeckt was mir sehr hilft, die Idee kam mir schon früher auf, aber die Umsetzung scheiterte an mangelnder Tatkraft.
Es ist ein wirklich sehr einfacher wie genialer Trick. Wahrscheinlich tun das nicht wenige, aber sie behalten es lieber für sich, da ich bis jetzt noch nichts im internet darüber gelesen habe.

Der Trick ist der das man mehrere Emule Instanzen parallel laufen lässt, ich habe es mit 2 probiert, das geht aber wahrscheinlich auch mit mehr.

Jede Emule hat natürlich eine eigene Incomming und Temp Ordner und laufen über separierte Ports.

Es gibt also ein Hauptemule und Nebenemules, Hauptemule dient ganz normal zum downloaden, die Nebenemules dienen zum beschleunigen.

Wenn ich eine Datei habe die wenig Quellen hat, dann lade ich die Datei in allen Emulen, das gilt natürlich auch für Dateien mit vielen Quellen, die ich ganz schnell runtergeladen haben möchte (das ist aber seltener der Fall).

Damit das effizient geht, vergebe ich unter den Emulen Friendupload, der upload geht ja nicht übers Internet und ist damit quasi unbegrenzt schnell (da sind 800-1000 kbit/s locker drin, aber mehr geht irgendwie nicht, da scheint es eine begrenzung zu geben aber egal).
Durch den Friendupload tauschen sich die emule clients die heruntergeladenen parts sofort aus und muss nicht nochmal aus dem Netz heruntergeladen werden.


Der Sinn ist denke ich ist klar, je mehr clients ich in der Warteschlange stehen habe desto öfter komme ich dran zum saugen.

Ich hab das bis jetzt mit 2 clients ausprobiert, müsste aber theoretisch auch mit mehr clients gehen.

Na was denkt ihr über die Sache?

tHe WiZaRd Of DoS 16. January 2009 18:54

Muahahahaaaa was für ein Schwachsinn looooooooool

Kabeljau 16. January 2009 19:00

Zitat:

Zitat von tHe WiZaRd Of DoS (Beitrag 139471)
Muahahahaaaa was für ein Schwachsinn looooooooool

Ach wirklich, immer noch besser als komplett sinnfreie Postings wie bei dir.
Ich verlange nicht viel von dir, sag doch einfach nur warum es Schwachsinnig ist.

tHe WiZaRd Of DoS 16. January 2009 21:43

Als Programmierer kann ich da eben einfach nur lachen und wenn ich das jetzt alles aufzählen soll, dann ist die Frage: wo anfangen?
Und das ist mir ehrlich zu doof, freu mich da auf eine evtl. Antwort von Stulle hehe

Caramon2 16. January 2009 22:18

Habe ich vor 1,5 Jahren mal probiert:

Vorteil: Man steht bei den Quellen 2x drin, kommt also auch doppelt so oft dran.

Nachteil: Beide Clients hatten dafür nur den halben Upload, wodurch das teilweise wieder kompensiert wurde, da man auch nur halb so viele Credits bekam.

Habe dann auch mal mehrere Mulis genommen: 3 ging noch, bei 4 bekam ich aber schon GDI-Probleme. (Icons waren schwarz und/oder kaputt, sonstige Grafikfehler, usw.)

Hatte ich mir der StulleMule-Mod probiert, die auf MorphXT basiert. Kann also sein, dass andere Mulis weniger/mehr Probleme damit haben.

Ich habe das aber schon lange nicht mehr gemacht. M.E. lohnt sich der Aufwand nicht, da es dadurch nicht viel schneller wird.

Stulle 16. January 2009 22:19

hey, bin ich irgendwie der schwarze mann? (wer DAS bild von mir kennt hält die klappe! :P)

ansonsten, wer soviel müll verzapft gehört gesteinigt. wir fassen zusammen, die selbe bandbreite an upload wird auf n clients mit n eigenen userhashes verteilt. somit kann jeder nur upload/n freigeben und damit auch nur 1/n mal so viele credits verdienen. der gewillte leser stellt fest: DAS MUSS GUT SEIN.... oder so... aber weiter im text. nachdem nun jeder sowieso nur 1/n mal so viele credits bekommt geben die clients auch untereinander noch upload frei. das bedeutet nun weiter, dass von upload/n pro client auch nochmal der friendupload weggeht bei dem client, der gerade zu einem "freund" uploaded. aber das ist natürlich gewollt. der verdatterte rationalist wird mir an dieser stelle die üblichen grüße zuwerfen (du spinnst, du hast ne macke, du bist verdauungsendprodukt, etc.), doch ich werde ihn belehren. es ist gewollt, weil auf diese weise können wir uns nicht nur selbst download generieren, nein, wir können uns auch noch - ein tusch - richtig unbeliebt bei anderen machen, weil uns quasi keine bandbreite mehr bleibt um unsere "schulden" zu begleichen. natürlich sind diese schulden irrelevant, denn wir haben das perpertuum mobile des up- und downloads. so dümmlich, dass es schon wieder genial ist. ein hoch auf unseren fischfreund!

PS: ja, du hasst mich jetzt, aber hassen ist so ein hartes wort... möchtest du nicht lieber eine aversion gegen mich hegen?

edit: caramon2, die aussage, dass man doppelt so oft dran kommt ist nicht richtig. man konkurriert nur mit sich selbst um die gleiche datei. in der queue geht es um multiplier, file prio und wartezeit. der multiplier kommt vom CS, die file prio vom nutzer und die wartezeit von einem zusammenspiel beider seiten. wenn ich mich also nun zeitgleich mit zwei clients anstelle, dann werden beide die selbe wartezeit haben und im worst-case-scenario auch den exakt gleichen chunk runter laden, weil sie gegenseitig noch garnichts von der frohen kunde wissen. außerdem verringert sich auch die stastische wahrscheinlichkeit ran zu kommen, wenn wir das mathematisch betrachten. sonst ist die chance vielleicht 1:n mit einem client ran zu kommen. bei zwei clients ist die wahrscheinlichkeit dann 1:[n+1] um mit einem client ran zu kommen. dabei ist n die zahl der wartenden clients.

Sorrow 16. January 2009 23:53

Zitat:

Zitat von Stulle (Beitrag 139476)
...wer DAS bild von mir kennt hält die klappe! :P)

...ok, dann sag ich mal nix weiter dazu... ;)

...da aber das eigentliche anliegen des threaderstellers so schön widerlegt ist, und bevor er hier noch zu "liebeleien" kommt...


#### closed ####


Alle Zeitangaben in WEZ +1. Es ist jetzt 10:02 Uhr.

Powered by vBulletin® Version 3.8.3 (Deutsch)
Copyright ©2000 - 2017, 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