eMule v0.47c StulleMule v4.5 [14.02.2007]

[Januar1956]

Zitat von Tom-XT

Hi,
Der Uploader mit nur geringer UL Bandbreite wird von Clients mit hoher UL Bandbreite verdrängt und um die Möglichkeit Credits zu sammeln gebracht;

PS.: in der nächsten offiziellen eMule Version sollten die Entwickler wieder zurück zur Maella Methode kehren!

Sorry, aber auf Einzelschicksale, die sich von ihrem 56k Modem nicht trennen wollen und auch ansonsten, sich zur Geiz ist Geil Gesellschaft zugehöhrig fühlen, kann leider keine Rücksicht genommen werden.

Aber im Ernst, Deine Ansicht ist völlig falsch. Das Prob fürs Netzwerk, ist weder das Zzul- noch das Maella System. Das Prob liegt darin, das der normalo User den Vollchunkupload aktiviert. In diesem Modus, werden Anfragen nach Chunkteilen, also keine ganzen Chunks, erst u.U. nach vielen Stunden, oder Tagen bearbeitet. Anders im Modus "kein Vollchunkupload", hier werden solche Anfragen bevorzugt abgearbeitet. Dieses im Gesamtzusammenhang des Netzweres, mit mehreren MIO Usern, ist zu einem gigantischen Uploadprob angewachsen, dem versucht jetzt das neue System entgegenzuwirken. Der Vorteil, ist eine deutlich schnellere Verfügbarkeit, der betroffenen Chunks. Dieses neue System ist demzufolge ein Reingewinn fürs Netzwerk.

Januar

[maulbongo]

Zitat von carlo

Moin, moin,

bin neu mit dem Stulle und werde von den Einstellmöglichkeiten schier erschlagen.

Habe folgendes Problem:

Nach jeder Fertigstellung eines Downloads kommen im Log die Meldungen:

ASFU: Detected change on shared folders, reload of shared files in 5 seconds...
ASFU: Reloading..
Server, Sendlist: Packet size xxx

Währenddessen (oder direkt danach) verlieren die Filees im Upload-Fenster kurz Ihren Namen und zeigen währendessen ein Fragezeichen, und die Queue wird geleert. Völlig!

An welchem Schalter muss ich drehen, um das Leeren der Queue zu unterbinden?
Das automatische Reload ist schon abgeschaltet, scheint aber nicht zu wirken, wenn der Reload durch das Fertigstellen einer Datei ausgelöst wird.


TIA
carlo

Nachtrag: Nachdem ich den Muli neu gestartet habe, wird nicht mehr nach jedem fertigen Download ASFU gestartet. Der Parameter "automatisches Reload " = aus wirkt jetzt anscheinend. Ein manuller Reload bleibt ohne Folgen für die Queue.

Hallo,

Diesen "bug" kann ich auch bei eingeschaltetem ASFU bestätigen, ich habe dieses Problem normalerweise nicht, allerdings habe ich momentan den Esel echt viel aufgehalst zum ziehen (was auch topp geht).
Aber mein System hat wirklich schwer zu Arbeiten (stört mich aber nicht weiter, da es ein extra Rechner nur für mule ist). Ich vermute stark, das leeren der Queue geschieht, weil das Sytem einen kurzzeitigen Hänger hat, da es ausgelastet ist. ???? Vielleicht benötigt das ASFU kurzzeitig hohe CPU , was bei starker Auslastung zum Hänger kommt ???

[Blomy]

Zitat von Januar1956

Sorry, aber auf Einzelschicksale, die sich von ihrem 56k Modem nicht trennen wollen und auch ansonsten, sich zur Geiz ist Geil Gesellschaft zugehöhrig fühlen, kann leider keine Rücksicht genommen werden.
Januar

So würde ich es aber nicht sehen. Client wohnt 8 Kilometer vom DSL-Verteiler weg.
Er/sie haben kein ISDN und bekommen wegen der weiten Entfernung vom Verteiler kein DSL.
Tja und damit sie sie angeschmiert. Ich kenne sogar 2 Leute, wo dieses. zutrifft.

[Tom-XT]

Zitat von Januar
Sorry, aber auf Einzelschicksale, die sich von ihrem 56k Modem nicht trennen wollen und auch ansonsten, sich zur Geiz ist Geil Gesellschaft zugehöhrig fühlen, kann leider keine Rücksicht genommen werden.

Hi,

Um die ging es mir weniger. Es gibt ja auch noch den TrickleSlot. Nach meiner Beobachtung werden recht häufig Downloads (auf einen Chunk bezogen) mit niedriger Datenrate eben von anderen Clients mit hoher Datenrate einfach verdrängt. Wenn der Client mit niedriger Datenrate (z.B. im TrickleSlot) keinen weiteren Chunk zu bieten hat, -> Abbruch, Pech für ihn (weniger Credits) und Pech für mich (weniger Download). Wenn nun aber der Client mit hoher Datenrate einen anderen Chunk beginnt hochzuladen als der mit niedriger Datenrate ist das von Vorteil für ALLE! Der im TrickleSlot laufende DL kann weiterlaufen, schaltet irgendwann in einen normalen UL, bekommt seine Credits und ich meine gewünschten Daten. Der mit hoher Datenrate beschenkt mich zeitgleich! mit einem weiteren Chunk über den ich mich freuen kann
Der geschilderte Fall trat in älteren Versionen merkbar seltener auf.

Aber im Ernst, Deine Ansicht ist völlig falsch. Das Prob fürs Netzwerk, ist weder das Zzul- noch das Maella System. Das Prob liegt darin, das der normalo User den Vollchunkupload aktiviert. In diesem Modus, werden Anfragen nach Chunkteilen, also keine ganzen Chunks, erst u.U. nach vielen Stunden, oder Tagen bearbeitet. Anders im Modus "kein Vollchunkupload", hier werden solche Anfragen bevorzugt abgearbeitet. Dieses im Gesamtzusammenhang des Netzweres, mit mehreren MIO Usern, ist zu einem gigantischen Uploadprob angewachsen, dem versucht jetzt das neue System entgegenzuwirken. Der Vorteil, ist eine deutlich schnellere Verfügbarkeit, der betroffenen Chunks. Dieses neue System ist demzufolge ein Reingewinn fürs Netzwerk.

Da bekomme ich jetzt aber ein Verständnis Problem.
Soweit ich weiss werden alle Dateien in Chunks mit 9,28MB Grösse aufgeteilt.
Z.B. 92,8MB Dateigrösse wären genau 10 Chunks.
Wenn nun der eigene Client möglichst nur vollständige Chunks senden soll dann habe ich es so verstanden, dass er erst dann einen Chunk zum UL freigibt wenn der Chunk auch komplett vorhanden ist. Was aber nicht heisst, dass der Empfänger von diesem Chunk nicht schon von einem anderen Client Teile bereits erhalten haben kann; er also einen unfertigen Chunk von meinem Client fertiggestellt bekommt. Möglichst vollständigen Chunk übertragen bedeutet somit lediglich dass möglichst immer 9,28MB (= Chunkgrösse) ausgehend von einem bei mir vollständig vorhandenen Chunk übertragen werden die sich dann aber auf mehrer Chunks beim Empfänger verteilen können; das entspricht auch so meinen Beobachtungen.
Warum sollten nun durch Aktivierung des Vollchunk-UL unfertige Chunks über unmässig lange Zeiträume nicht bearbeitet werden, leuchtet mir nicht ein. Der Client sollte unfertige Chunks bevorzugt anfordern, bekommt diese dann von Clients die den Chunk bereits komplett zur Verfügung stellen können und ein weiterer Chunk wird angefangen nur nicht fertiggestellt da nur 9,28MB + Blockfertigstellung übertragen werden. Ich meine man sollte eher hier ansetzen und das UL-Verhalten dahingehend ändern dass bei angefangenen Chunks grundsätzlich versucht wird diese fertigzustellen und damit das fix eingestellte UL-Limit von 9,28MB (9,28MB = Chunkgrösse aber =! "vollständiger Chunk") stattdessen dynamisch zu regeln. Dann entstehen automatisch nurnoch sehr wenige unfertige Chunks und das "Problem" erübrigt sich von selbst. Ursachenbekämpfung statt an Symptomen rum-zu-doktoren
Das wäre progressiver Fortschritt/Verbesserung

Viele Grüsse, Tom

PS.: ob eine wie oben beschrieben dynamische UL Regelung machbar wäre kann ich nicht beurteilen; bin nicht vertraut mit den Interna/Protokollen von eMule. Ist als theoretische Überlegung zur Diskusion gestellt.

[Januar1956]

@ Tom-XT

Werf mal einen Blick in Deine Statistik und sieh Dir mal Deine Werte für:
a, durchschnittlicher Upload und
b, durchschnittlicher Download an,

vielleicht wirds dann verständlicher. eMule fragt niemals nach einem vollen Chunk nach, sondern nur nach ein paar kb, wenn der angefragte User aber Vollchunkupload aktiviert hat und zudem auch noch, einer von wenigen Quellen ist...ist Sanktnimmerleinstag angesagt...wenn er nicht sogar die Dat aus dem Share nimmt. Im neuen System besteht eine deutlich bessere Aussicht auf Erhalt der Dat.

Januar

[Tom-XT]

Hmm, nö, der Blick in die Statistik macht mir diesbezüglich nix klarer, ich sehe nur, dass ich im Schnitt mehr Up- als Download habe.

a, durchschnittlicher Upload/Session: 9,18MB
b, durchschnittlicher Download/Session: 6,25MB

hab ich Tomaten auf den Augen, stehe auf der Leitung

Wenn eMule nur ein paar KB anfragt, der angefragte Client diese paar KB in dem zugehörigem Chunk verfügbar hat, dieser Chunk beim angefragten Client dann vollständig vorhanden ist, er Vollchunkupload aktiviert hat, dann muss ich doch nicht länger warten als wenn er Vollchunkupload deaktiviert hat. Nur wenn der Client diesen Chunk NICHT vollständig hat heisst es warten da der Chunk respektive die von meinem Client gewünschten KBs nicht zum UL freigegeben sind. Oder ist das falsch?

Vollchunkupload bedeutet ja nicht dass NUR vollständige Chunks (9,28MB!) hochgeladen werden können, wenn dem so währe, würden Dateien ja teilweise NIE fertiggestellt. Z.B. Stichwort 24std Zwangstrennung die jeden UL/DL nunmal unterbricht und damit unfertige Chunks erzwingt.

Vollchunkupload bedeutet, so hab ich es jedenfalls bisher verstanden, dass nur vollständig vorhandene Chunks zum UL freigegeben werden und eben besagte 9,28MB (Chunkgrösse) versucht werden zu laden; unabhängig davon ob der Empfänger nur wenige KB/MB dieses Chunks benötigt. Was über die wenigen angefragten KB/MB hinaus geht wird, wenn möglich, von einem nächsten Chunk geladen oder der UL wird abgebrochen. Das ist was ich auch so beobachten kann.

Daher mein Verständnis-Problem.

Viele Grüsse, Tom

[Januar1956]

Nö, so ist es nicht. Vollchunkupload bedeutet, es wird jeder einzelne, schön brav, der Reihe nach abgeschickt...Vielleicht doch mal wieder eine eMulehilfe Lesestunde einlegen.
Grundsätzlich landet jede Anfrage auf Platz 5.000 der Warteliste. Eine kleine Dat Nachfrage, wird bevorzugt abgearbeitet, wenn Vollchunkupload nicht eingeschaltet ist. Ist er eingeschaltet, muß sie gnadenlos durch, so lange es auch dauert und so weh es auch tut.
Daran hat sich zwar jetzt auch nix geändert, aber durch das Bedienen des einzelnen Chunk durch, wieviel auch immer User...wird diese Schmerzerfahrung gelindert.

Januar

[Tom-XT]

Vollchunkupload bedeutet, es wird jeder einzelne, schön brav, der Reihe nach abgeschickt...Vielleicht doch mal wieder eine eMulehilfe Lesestunde einlegen.

ok, ist schon länger her...

Wenn dem so ist, dann wird die Sache schon klarer.
Kleine Dats (kleiner als 9,28MB) share ich fast nie, in der Regel sind die Dats deutlich grösser als 100MB; daher auch keine Erfahrungswerte in der Richtung. Ich beziehe mich damit auf das Sharen grösserer Dateien und die dabei verwendete Chunkbehandlung.

Dank Dir und viele Grüsse, Tom

[Januar1956]

Kleine Dats (kleiner als 9,28MB) share ich fast nie, in der Regel sind die Dats deutlich grösser als 100MB;

Du hast es nicht verstanden! Es geht nicht um die ganze Dat, sondern, um jeden einzelnen Chunk.
...macht aber nix...ist eh inzwischen etwas OT.

Januar

[maulbongo]

Zitat von maulbongo

Hallo,

Diesen "bug" kann ich auch bei eingeschaltetem ASFU bestätigen, ich habe dieses Problem normalerweise nicht, allerdings habe ich momentan den Esel echt viel aufgehalst zum ziehen (was auch topp geht).
Aber mein System hat wirklich schwer zu Arbeiten (stört mich aber nicht weiter, da es ein extra Rechner nur für mule ist). Ich vermute stark, das leeren der Queue geschieht, weil das Sytem einen kurzzeitigen Hänger hat, da es ausgelastet ist. ???? Vielleicht benötigt das ASFU kurzzeitig hohe CPU , was bei starker Auslastung zum Hänger kommt ???

Hallo,

Ich habe das Problem bei mir gefunden und auch eine Lösung parat:

Bei mir war die Funktion "emule process in high priority" aktiviert (standardmäßig ist die allerdings ausgeschaltet).

Da mein Rechner momentan wirklich stark ausgelastet ist und der StulleMule sehr viele Downloads drin hat entsteht hier der Flaschenhals.

Es sieht so aus: Verschiebt man die Datei, so startet der StulleMule unverzüglich ASFU (falls aktiviert).
Auf Grund dessen, dass der StulleMule aber high priority hat und das System bei mir schon an der Leistungsgrenze ist gibt es nun hier einen Hänger, Windows verschiebt die Datei, nahezu zeitgleich mit dem Start von ASFU, die I/O Anfrage kann aber von Windows nicht direkt abgearbeitet werden, da ASFU in high priority am Arbeiten ist, nun hängt der StulleMule für einen kleinen Moment (genau dann, wenn die Datei als fertig verschoben wurde), dies hat dann zur Folge, dass die Queue schlagartig geleert wird.
Ich konnte das heute den ganzen Tag über mehrmals reproduzieren.
Ich habe den StulleMule anschließend auf "normal priority" gestellt und gleiche Versuche erneut gemacht.
Nun ist der I/O Fluss gleichmäßig und Windows kann die Datei schnell genug verschieben und ASFU wird nicht behindert und der StulleMule hängt auch nicht, die Queue bleibt weiterhin gefüllt (habe ich auch mehrere male reproduziert).
Anmerkung: Das Verschieben fand bei mir nur auf der gleichen Festplatte statt, wie es ist, wenn von einer zur anderen Festplatte verschoben wird kann ich daher nicht sagen.
ich hoffe das hilft auch bei anderen Leuten mit diesem Problem.
Wünsche eine geruhsame Nacht.

[maulbongo]

Guten Morgen Stulle,

Ich habe hier ein crash dump für Dich, hoffe das hilft weiter.

[maulbongo]

Hallo Stulle,

Hier ein weiteres crashdump.

[sinsemillah]

Hi!
Ich hab den Mod jetzt installiert aber hab keine Server/Servermet und kann auch nicht zu manuel hinzugefügten Servern verbinden.
Bitte helft mir, ich habs nicht drauf!
sinsemillah

[tango2002a]

@sinsemillah

http://www.emule-mods.de/?servermet=show

Server mit linker Maustaste anklicken.

Schau unter "Server".

Verbinden.


Grüße

tango

[Muio]

Habe mal eine frage
welche datein muss ich übernehmen....von alten zum neuen esel ?
das ich auch alles habe was ich hochgeladen freunde...usw...halt nur dich wichtiggsten sachen !