eMule-0.30e-gnaddelwarz-1.3.2 [18.12.2003]

**Gnaddelwarz** · 4. January 2004, 03:53

Zitat:

Zitat von Kaeptn_Sperrmuell

Zur Batch:
Die wuerde doch auch nur die Zeitangaben "resetten", sofern ein Neustart des emule angesagt ist?

Gesetz den Fall Client xy saugt an Tag a am File b
File b wird bei mir fertig, ich nehms raus
Client xy fliegt zwangsaleufig raus aus meiner Queue
3 Tage spater kommt Client wieder daher, will an File c saugen
Dieser hat (durch nichtaustauschen der .met Datei) dann dennoch eine Wartezeit von 3 Tage und ...Stunden?
-> Zeit wurde nicht resetted?
Woher auch?

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.

Zitat:

Emule laeuft immer noch und es wird dennoch die damals gesopeicherte Zeit angezogen (->am Tag a an File b gewesen)?!
Dadurch bekommt er wieder nach drei Tagen "Abstinenz" einen Mega QR zugeschrieben?!

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.

Zitat:

Rekord liegt jetzt bei 8 Tage 9 Stunden
Das File lag vorher auf "sehr niedrig", seit 2 Stunden auf REL (kein Powershare)
Und das mit einer Laufzeit von knapp 9 Stunden mit SUQWT?
-> kann es sein, dass REL+Wartezeit zu hoch multipliziert/addiert werden, oder so?
-> REL funktioniert imho bestens (steht auf 512 bei mir)

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.

Kaeptn_Sperrmuell · 4. January 2004, 13:57

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

hubutz · 4. January 2004, 14:32

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

Kaeptn_Sperrmuell · 4. January 2004, 14:40

hubutz,

Du hast recht!
habe

Zitat:

der Client kommt nun nach 3 Tagen wieder um eine Datei anzufragen. Dieser Client beginnt nun nicht mit 0 sondern mit 8 Stunden Wartezeit

geistig verdraengt...
Asche auf meinen Alzheimer

Gruesse
Kaeptn

hubutz · 4. January 2004, 14:43

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

**Gnaddelwarz** · 4. January 2004, 16:47

Zitat:

Zitat von Kaeptn_Sperrmuell

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.

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.

Kaeptn_Sperrmuell · 4. January 2004, 18:57

habe mal die BoardSuche intensiv gequaelt und in diesem Thread folgendes vom Meister sivka gefunden:

Zitat:

Zitat von sivka

Zitat:

FEATURE: One Chunk Sharing - Serial (good for releasing!) [by SlugFiller]
= You can choose to make hide overshares stricter by only revealing one chunk to each user, starting
= with the least uploaded chunks, and considering the chunks that were already offered when choosing
= the next. Hide overshares must not be disabled for this to work(Off by default).

dieses feature ist gut für releaser. der remote client sieht nur einen chunk,
den er downloaden kann, rest bleibt rot. chunks werden seriel verteilt,
sprich ohne wiederholung bis der ganze file raus ist, dann alles von vorne.
chunks werden zufällig ausgewählt. wendet dieses feature nur für die
neuen releases an.

Zitat:

FEATURE: Prevent Chunk OverSharing - Hide OSC (0 -> Off) [by SlugFiller]
= This feature attempts to balance the amount of time different parts of each file are uploaded,
= by not revealing to other users parts that have been uploaded a certain amount of times more than
= others, making them only download the parts that have been uploaded less. It uses the data from
= the spreadbars to decide how many times each part was uploaded. It ignores, of course, any parts that
= either you don't have, or that the other user already has, so that at least one part that can be
= uploaded is always revealed to the other user. You can set the amount of times a part has to be uploaded
= more than others before it's hidden, or 0 to disable(Default: 5).

dieses feature sorgt für bessere verteilung der chunks. man kann hier
einstellen, wie oft darf ein und derselbe chunks heruntergeladen werden
bis er unsichtbar wird (Default: 5). bei 0 wird das feature abgeschltet und
dann dürfen alle clients bei dennen z.B. nur der eine chunks fehlt auch
beliebig oft runterladen.

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

AdiS · 4. January 2004, 20:53

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

Nur die ganz Schlauen und Hartnäckigen durchschauen den Trick.

Adios
AdiS

Kaeptn_Sperrmuell · 5. January 2004, 00:36

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:

und hier mit 200 Sekunden Verzoegerung:

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

**Usul** · 5. January 2004, 08:04

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

Kaeptn_Sperrmuell · 5. January 2004, 09:31

Hi Usul,

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

Gruesse
Kaeptn

**Usul** · 5. January 2004, 13:57

Zitat:

Zitat von Kaeptn_Sperrmuell

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

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.

hubutz · 5. January 2004, 15:35

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

luka · 5. January 2004, 17:39

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.

Hopie · 10. January 2004, 14:14

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

egal welche ich nehme.. alle veraltet und werden ersetzt

Ähnliche Themen: eMule-0.30e-gnaddelwarz-1.3.2 [18.12.2003]