eWombat Version 0.062 01.07.03 (bugfixes und verbesserungen)

[badtaste]

@MxM

ein slot per file erhöht definitiv die CPU Last

falsch!!
hier kannste nachlesen, das dieses system (bei bloodymads mod) nicht zu erhöhtem resourcen verbrauch führt :
http://www.emule-project.net/board/i...ST&f=2&t=13880

und es is kein schnickschnack, wenn man erreicht, das auch arre files vernünftig downloadbar sind..

[MxM.]

und wie siehts aus mit dem erhöhten traffic ? ...wobei ich auch immernoch nicht verstanden habe, warum vermehrtes zuordnen nicht mehr Prozess verursachen sollte ?!

übrigens du sagst falsch... die genaue antwort aber war:

In bloodymad implementation there is no noticeable increase (if there is) in ressource need.

no noticable. nun ich kenne auch einige die sagen... ihr emule behindert sie bei ihrer sonstigen arbeit am pc nicht, andere können den PC garnicht benutzen dabei.

und es standen noch andere interessante sachen da:

Well, I don't see any reason not to have the queue as it is and tweak auto priorities to push rare files. We already have all that we need. Why change? It's only a matter of tweaking the current system.

und genau das meine ich auch... du veränderst etwas am system... und was wir hier machen ist nicht das system verändern ... sondern sparen.. alles überflüssigen geschichten abschaffen... und ich denke einfach, dass multiple queues nicht nötig sind.

emule 0.28a hat durch part sent selbst die möglichkeit zu sehen, wie sehr ein file spreaded ist... und nicht umsonst ist schon rare chunk im system inbegriffen... und glaubst du auch nicht, dass rarechunk in den einzelnen queues mehr last verursacht ? ... dann gibts ja in jedem fall in jedem queue einen raresten chunk... da könnte es durchaus passieren, dass ein insgesamt wichtigerer chunk garnicht zum zuge kommt.

konstruieren wir mal folgendes:

ich habe 4 slots zur verfügung.
ich habe 100 files, also 100 queues.
1000 user befinden sich in der warteschlange. idealfall 10 pro file.
von meinen dateien sind genau 10 von mir selbst... also garnicht anderweitig verfügbar.

der normalfall mit einem queue verschafft jetzt immer wieder meinen files die vorderen plätze....

dein system mit mehreren queues schiebt aber sehr definitiv jemanden aus den anderen queues vor. die 90 anderen files haben ja alle einen eigenen queue... und innerhalb dieser queues gibts auch rarest chunks.

welche dateien bevorzugt nun emule... und glaubst du immernoch, dass die verwaltung nicht zumindest komplexer ist ? welcher user bekommt nun einen der 4 slots ?... und wer kommt danach... ich habe immerhin 100 queues...die doch schlussendlich eh untereinander berechnet werden müssen.

ich geb dir in einem punkt recht... manchmal ist es gerade durchs releasen schwierig... und mit den multiple queues wollte man verhindern, dass man mehrere emules gleichzeitig laden muss, u.a. auch wegen der credits und den unterschiedlichen hashes. aus meiner sicht ist es aber sinnvoller 2 emules laufen zu lassen, beide auf 2 slots... einen zum releasen, so dass dauerhaft nur meine files gesendet werden... und einen für den normalen transfer.

nennt sich in meinen augen mehr transfair, als die 100 queues... und bei mir sinds schon 131 files...


ich bin gern bereit anhand eines gegenbeispiels meine auffassung zu ändern... sollte aber ruhig und plausibel ablaufen.

[badtaste]

queue per file bedeuted, das alle files gleich behandelt werden,
also der neueste "urlaubsfilm", den jeder haben will, und die"urlaubsfotosammlung", für die nur wenige quellen da sind.

das bedeuted:
bis jetzt ist es so (ich habs selbst immer und immer wieder gesehen), das beliebte files scheinbar erreichbarer sind, was aber bur daran liegt, das die 500 leute, die den urlaubsfilm wollen, die Queue belegen, und der eine, der meine fotosammlung (blödes beispiel aber egal)laden will bleibt auf der strecke, wenn jetzt noch die 500 leute nen urlaubsfilm haben, den ich haben möchte, dann kommen sie durchs CS noch schneller nach vorn, die 200, die nachziehen ebenfalls, aber der eine, der die sammlung will, guckt in die röhre...

prioritäten oder rarest chunk braucht man bei sonem system garnet mehr, da es sich von allein regelt, das man immer auch an seltene files rankommt, somit fällt ne menge traffic weg, den du erwähnt hast.

so long...

badtaste

[MxM.]

ist doch das gleiche problem oder ? welcher queue wird bevorzugt ? was entscheidet nun, welcher queue zuerst, und welcher zuletzt rankommt. eigentlich ist nur eine instanz zwischengeschaltet. m.E. eine zuviel.

[badtaste]

es bedeuted vor allem chancengleichheit...
ich hab dieselbe chance ein sehr beliebtes und verbreitetes file zu laden, wie auch ein besonders seltenes... ich sehe da keinen nachteil???

[Usul]

Darf ich mal was einwerfen? Ich habe noch nie einen Mod mit einer Queue pro Datei gehabt, aber bei mir stellt sich folgender theoretischer Vorteil dar, vielleicht irre ich mich auch: Die Leute, die eine rare Datei von mir runterladen wollen, kommen zuverlässiger in eine Queue. Wenn ich eine Queue für alle Dateien habe, kommen natürlich die rein, die anfragen, und das man zu verbreiteten Dateien häufiger Anfragen bekommt, ist klar. Blöd ist halt nur, wenn dann jemand eine seltene Datei von mir haben will, die ich auf Release stehen habe, der aber nicht in die Queue kommt, weil die von Leuten blockiert wird, die "unwichtige" Dateien haben wollen. Wenn es für jede Datei eine Queue gäbe, dann würden die Queues der verbreiteten Dateien schnell vollaufen, aber die Queues der seltenen Dateien wären nie richtig voll, sprich, es wäre immer ein Plätzchen frei für jemand, der etwas haben will, was bei mir auf Release steht und selten ist.

Funktionieren mehrere Queues wie beschrieben, sprich, würde es aus der Sichtweise etwas bringen? Ich finde es einfach blöd, wenn ich die seltene Anfrage nach einer seltenen Datei von mir abweisen muß, weil meine Queue wieder verstopft ist mit Uploadanfragen, die mir nicht so wichtig sind.

[badtaste]

@Usul:

Genau das is der Punkt!!
endlich versteht mich jemand!!!*freuhüpf*


sollten wir uns jemals über den weg laufen (festival oder so), haste mindestens ein Bier gut

so long...
badtaste

[MxM.]

ich glaub immernoch, dass emule sich dann entscheiden muss, welcher queue zuerst rankommt. und damit stellt sich das problem der entscheidung genauso, nur eben später.

laut deiner aussage , wenn also mehr chance besteht in den queue zu kommen... dann würde das wiederum heissen, mehr belastung... weil mehr verbindungen gehandelt werden müssen. wenn das so nicht gemeint ist, muss emule wie oben gesagt die queues priorisieren. auch wenn bei dem priorisierungsprozess schon einige dateien zusammengefasst sind und emule sich nurnoch entscheiden muss welche datei wichtiger ist... aber das kommt m.E. aufs gleiche raus, als wenn er sich gleich entscheiden muss... und so kann er wenigstens von allen den raresten chunk heraussuchen und muss nicht zuerst den raresten chunk in jedem einzelnen queue berechnen und dann den raresten queue... oder so ähnlich... schlussendlich , wenn ich mir vorstelle, da hat einer 2000 dateien.... also 2000 queues.... jeder queue hat 100 leute... ich weiss nicht wie du dir das vorstellst... 200000 anfragen bearbeiten.... bedeutet die 6 slots auf 2000 queues entscheiden... innerhalb der 2000 queues den raresten chunk oder längste wartezeit oder credit nach vorn berechnen.... also ich vermute, dass man so viel eher kein korrektes QR bekommt.

ich steh auf dem queue meiner datei auf QR1 .... super... emule zieht aber erstmal die 1999 ersten der anderen queues vor... dann nutzt mir mein QR1 garnichts, oder ?

[badtaste]

Die Anzahl der Anfragen bleibt die selbe, sie wird nur auf mehrere queues (eine pro file) verteilt...
deine rechnung geht also nicht auf...
die reihenfolge ist identisch mit der jetztigen reihenfolge.. wonach entscheidet emule denn bis jetzt, wer als erster laden darf??? der, der zuerst da war, odert der der den meisten credit hat...

so long...

badtatse

[Usul]

Ich wollte eigentlich nur sagen, das Emule dir unterschiedlichen Prioritäten der einzelnen Dateien nur dann auswerten kann, wenn die Clients schon in der Queue sind. Eigentlich müßte schon beim Eintritt in die Queue priorisiert werden, d.h. Clients, die Dateien mit Release-Priorität haben wollen, kommen mit einer höheren Wahrscheinlichkeit in die Queue als andere. Da das aber nicht geht, wäre die Lösung mit mehreren Queues zwar ein Krücke, aber immerhin ne Hilfe. Das sich dann wieder Probleme mit der Verwaltung auftun, eventuell mehr Last etc. ist wieder ne andere Geschichte. Aber Emule hat dann wenigstens die Chance etwas zu machen. Wenn die Leute mit Release-Dateiwünschen nicht in die Queue kommen, kann Emule überhaupt nichts machen.

Zur Situation bei mir: Ich biete momentan 26 Dateien an, das meiste (19) sind Downloads, die gleich wieder geshared werden. Die Downloads stehen meist bei der Uploadpriorität auf sehr niedrig, weil die Dateien schon gut verbreitet sind. Dann habe ich noch 7 seltene und schlecht verbreitete Dateien, die ich nur noch im Share liegen habe, die sind alle auf Release gestellt (außerdem ist noch ein Download auf Release-Uploadpriorität). Also hab ich 8 Dateien, die auf Release stehen, und 18, die auf sehr niedrig stehen. Ich habe eine Queue von 2000, und jetzt kommt der Hammer: In meiner Queue sind sage und schreibe 6 Clients, die eine der Release-Dateien haben wollen. Das mehr Bedarf besteht, sieht man an den Anfragen, es sind zwar nicht viele, aber sie sind vorhanden und kommen nicht zum Zug. Ich habe eine Release-Datei, die ich schon ewig im Share habe, von 1881 Anfragen wurden 190 akzeptiert. Das ist in etwa das gleiche Verhältnis wie bei den Dateien, die auf "sehr niedrig" stehen. Und genau das ist es, was ich mir bei mehreren Queues als Verbesserung vorstelle. Dummerweise hab ich noch keine Mod gefunden, der dieses Feature hat und bei dem auch der "Rest" stimmt

[darkwolf]

Hi @All
bin ausgeschlafen

Beim 003 habe ich noch einen kleine Bug in der Slotverwaltung, der wird aber mit der 004er behoben.

Bei den experimental einstellugnen kann man mal schrittweise die werte um jeweils 10 sekunden verringern, ein neues File in den download stellen und schauen was und ob etwas passiert. Keine Angst bei einem neustart vom Wombat werden diese beiden Werte wieder auf default gestellt.

@MxM
eMule arbeitet leider nicht über dem Idle-Timer sondern mit WM_TIMER. Mein Ziel ist es für die Upload/Dowload Queue je einen globalen internen Scheduler zu verwenden der von der verfügbaren tatsächlichen Bandbreite abhängig ist. (Ist dann wie Multitasking, bloß mit den Clients in den Queues). Files die nichts/kaum etwas finden werden dann mit einer niedrigeren Priorität und nicht so oft abgefragt.
Ist aber nicht zu verwechseln mit dem jetzigen Pseudo Prioritäts System. Das sorgt nur dafür das alle Queues 3* durchlaufen werden.

Umfrage:
Ist es euch wichtig das ihr immer sehen könnt was für Client-Versionen in den Queues sind ?

cu
darkwolf
(wieder fleißig am coden... )

[badtaste]

nich so wichtig, aber einige (zb.Shareaza) sollten gar nicht erst in die warteliste kommen..
also leecher schon vor der queue abblocken

so long


bad taste

[Odinasgardson]

Umfrage:
Ist es euch wichtig das ihr immer sehen könnt was für Client-Versionen in den Queues sind ?

mir nicht wirklich.

mfg
Odinasgardson

[Hoermaenn]

Bin dafür. Weil ich schon wissen will welche Version von mir leecht
Aber wenn ihr das realisieren könnt was ihr hier redet dann wirds interesant.

[Vip2002]

Nur Interessehalber,

hat mal einer der Tester hier die CPU und RAM Last im Auge behalten?
Liegt die wirklich wie zu erwarten unter den anderen aktuellen Mods? z.B. LamerzChoice?

Was ich hier lese klingt nämlich verdammt interessant, da ich auf der Suche nach einem schlanken Client bin, der möglichst wenig Ressourcen benötigt und trotzdem gute Up/Downraten hat.

Achja, die Daten wer bei mir saugt interessieren mich nicht wirklich, da es mir eigentlich egal ist. Ich bin der Meinung, dass sich das auf Dauer eh egalisiert. Vielleicht könnte man die gesamte Statistik als PlugIn realisieren?