Hm, ja, war ein Denkfehler meinerseits. Mein Gedanke war, dass sich die beiden verschiedenen clients.met ja nur durch SUQWT unterscheiden, ich habe aber nicht bedacht, das die Strukturen im Arbeitsspeicher die Wartezeit ja weiterhin speichern.

Also vergiss das mit der Batchdatei.
Nicht ganz. Es wird nicht gespeichert "am Tag a an File b", sondern "war irgendwann schon mal für x Stunden in der Queue", dh es wird nicht das Datum sondern die Wartezeit gespeichert. (Auch das angefragte File wird nicht mit abgespeichert)
Also:
Ein Client fragt eine (beliebige) Datei an und muss natürlich in der Queue warten (was ohne "Powershare" ja der Regelfall ist).
Er wartet z.B. 8 Stunden (ohne Upload zu bekommen) und "verschwindet" nun aus der Queue. Dafür kann es verschiedene Ursachen geben:
- man hat selber seinen Client neugestartet,
- der andere hat seinen eMule (für längere Zeit) beendet.
- der Client braucht die Datei nicht mehr (schon mit Hilfe anderer Quellen komplett)

Angenommen, der Client kommt nun nach 3 Tagen wieder um eine Datei anzufragen. Dieser Client beginnt nun nicht mit 0 sondern mit 8 Stunden Wartezeit. Das ist nur fair, dieser Client hat diese Zeit ja (irgendwann mal) in der Queue verbracht, ohne etwas dafür zu erhalten.
Nun, ich habe eine Datei auf "sehr niedrig", ein Client der diese Datei dann mal läd hat im Schnitt 15-20 TAGE Wartezeit. Die durchschnittliche Wartezeit für "normale" Dateien (Prio AUTO, kein PS) ist bei 1-2 Tagen.

Da ich eMule nie 15-20 Tage durchlaufen lasse, hätten Clients, die diese Datei haben wollen, ohne SUQWT keine Chance diese zu bekommen.
Man könnte fast behaupten, ohne SUQWT könnten wir auf Upload-Prioritäten verzichten, denn dann würde die Datei nie hochgeladen werden, also könnte ich sie auch aus dem Share ganz heraus nehmen.

Hi Gnaddel,

Danke fuer Deine aussagefaehigen Erlaeuterungen.
Irgendwie hebelt sich das SUQWT damit doch selber aus?!

Beispiel
Ich forder eine Datei an, 300 Quellen gefunden, 100 arbeiten mit SUQWT.
Lasse sie 2 Stunden laufen, bekomme dann im besten Fall bei allen 100 SUQWT Clients einen QR.
Dann breche ich den DL der Datei ab (aus welchen Gruenden auch immer).
Eine Woche spaeter starte ich den DL der Datei wieder. 80 der SUQWT Clients sind immer noch mit der Datei unterwegs, bei denen bekomme ich zwangslaeufig einen aeusserst hohen QR, da meine vermeintliche Wartezeit 7 Tage betraegt.
-> bringt anfangs einen MegaDownload

War nur so ein Gedankenspiel...

Aber lassen wir das Thema SUQWT mal, wurde imho sehr ausfuehrlich und aufklaerend diskutiert.

Wie sieht es denn aus mit dem HOS?
Wenn ich den Wert X erreicht habe, geht ja (so gut wie) nichts mehr von dem File raus. Wird der Wert irgendwann wieder auf Null zurueckgesetzt? Bleibt der ewig bestehen?
Wenn ich eine Datei mit erreichtem Wert aus dem Share nehme, Monate spaeter einen ReShare machen will, dann sit der Wert erreicht und ich kann es nicht ReSharen, ausser ich deaktiviere den HOS Wert oder erhoehe ihn?!
Ist das so korrekt von der Denkweise?
-> Der HOS Wert wurde in diesem Thread auf Seite 9 um So Dez 28, 2003 14:43 im Detail schon mal angefragt und AdiS interessiert sich auch fuer die Verfahrensweise beim HOS.

Koenntest Du da bei Gelegenheit auch sachdienliche Hinweise einbringen?

Danke und Gruesse
Kaeptn

Kaeptn_Sperrmuell, einer von uns beiden hat das mit dem SUQWT falsch verstanden... Dein Beispiel hat (meiner Auffassung nach) einen entscheidenden Denkfehler, und zwar glaube ich, dass dir nur die Zeit angerechnet wird, die du wirklich in der Schlange warst... Also hast du nach deiner Woche 2h "Gutzeit" bei den Clients die noch da sind... Falls ich falsch liege bitte korrigieren...

hubutz,

Du hast recht!
habe geistig verdraengt...
Asche auf meinen Alzheimer ;)

Gruesse
Kaeptn

Kein Problem... Aber deine Theorie wäre für mich sehr praktisch gewesen... Kann meinen Muli leider net so lange anlassen (und hab ganz selten mal so 24h Tage)... Da würde mir das nach deiner Theorie richtig viel bringen ;)

Also, wenn ich HideOS richtig verstanden habe, dann bezieht sich der Wert nicht auf die absolute Anzahl, sondern auf die Differenz zum am wenigsten gesharetem Teil.
D.h. der HideOS-Wert gibt nicht an, wie oft ein Chunk heruntergeladen werden darf, sondern wie viel öfter als andere Chunks.
Beispiel:
Chunk 1 wurde 10 mal hochgeladen, Chunk 2 12 Mal und Chunk 3 16 Mal.
Bei einem HideOS-Wert von 5 dürften nur noch die ersten beiden Chunks hochgeladen werden. Chunk 3 ist erst wieder erlaubt, nachdem Chunk 1 hochgeladen wurde.

habe mal die BoardSuche intensiv gequaelt und in diesem Thread folgendes vom Meister sivka gefunden:
Damit wirds glasklar! Siehe auch Gnaddels Uebersetzung ein Posting hoeher, mit dem aeusserst anschaulichen Beispiel.
Damit duerften meine Fragen soweit geklaert sein und ich werde versuchen nicht mehr zu nerven.
->Ansonsten laeuft der Gnaddel wie gewohnt stabil und in bester Form. :)

Gruesse
Kaeptn

Hallöchen

Danke für Eure Recherche-Arbeit.

Inzwischen bin ich aus theoretischen und praktischen Gründen zum Schluss gekommen das HideOS nicht sehr effizient ist. Da vertraue ich lieber auf die neueren Mulis, die nehmen ja heutzutage nicht mehr jeden beliebigen Chunk, sondern versuchen mit mehr oder weniger Erfolg den selteneren Chunk zu ergattern oder zu komplettieren.

Das One Chunk Sharing ist da schon viel besser, wenn man releasen will und das File komplett hat. Nachteil: Die Sauger sehen anfänglich nur Rot und das schlägt auf die Psyche.... :mrgreen: Nur die ganz Schlauen und Hartnäckigen durchschauen den Trick. :wink:

Adios
AdiS

jetzt bin ich´s schon wieder :(
Zeit zum spielen gehabt... mit der Statistik diesmal ;)

Einstellungen
Graph Verzoegerung: 200 oder 120 Sekunden
Statistik-Baum: 5 Sek. Verzoegerung

Siehe hier mit 120 Sekunden Verzoegerung:
http://www.cabernet.ch/jockinger/pic...mods/dl12h.gif

und hier mit 200 Sekunden Verzoegerung:
http://www.cabernet.ch/jockinger/pic...mods/dl20h.gif

Was faellt auf?
Andere Zeitangabe an der X-Achse, gleiche Grafik...
Stoert mich echt nicht, nur "fuer´s Protokoll", dass man da nochmal nachsehen sollte.
Dieses Phaenomen fiele bei mir unter "PRIO4" rein ;)

Gruesse
Kaeptn

@Kaeptn_Sperrmuell

das ist bei jedem Emule so. Wenn man die Skalierung der Statistik ändert, wird nicht die gesamte Grafik neu berechnet, sondern alle neu hinzukommenden Werte werden nach der neuen Skalierung eingetragen. Irgendwann stimmt dann der ganze Graph wieder, wenn alle "alten" Werte nach links rausgewandert sind. Aber sofort mit neuer Skalierung anzeigen lassen geht meines Wissens nach nicht. Vielleicht sollte man bei Änderungen an der Skalierung den gesamten Graph einfach löschen, dann würde sich niemand wundern.

Hi Usul,

ich koennte mich erinnern, dass der Gnaddel 1.2 dies komplett neu gezeichnet haette, aber wie gesagt, stoert mich nicht.

Gruesse
Kaeptn

Wenn das so ist, dann hab ich nichts gesagt ;-) Ist mir bisher aber noch nicht untergekommen, das das bei einem Mod so gewesen ist. Allerdings schraub ich auch nicht ständig an diesen Einstellungen rum. Die erwähnte Version habe ich wohl nicht probiert, vielleicht ist es ja so drin.

Hmm... Heute der Erste Bug im Gnaddel, auf einmal Prozessorauslastung über lange Zeit (über 15 Minuten bei 95%+), hab ihn dann gekillt... Einfach mal den Gnaddel neugestartet, selber Fehler... Vielleicht gehts nach einem Reboot wieder... Mal abwarten... Hatte von euch auch schon mal einer so ein Problem?

Edit

Nach nem Reboot des PC läuft der Gnaddel wieder einwandfrei (naja, er hat aber meine Prefercences und die Clients.met abgeschossen :( )... Also sehr eigenartige Sache...

Ja, das hatte ich auch schon mal, aber mit irgendeiner uralten Version. Das ist also schon eine ganze Weile her. Es lag damals ebenfalls an einer zerstörten clients.met, die man heutzutage aber Dank automatischem Backup wieder ersetzen kann. ;)

welche clients.met kann ich für andere mods benutzen???

egal welche ich nehme.. alle veraltet und werden ersetzt :(