eMule 0.46c Xtreme 4.6 [22.10.2005]

[aalerich]

Hmmm, ich habe gerade nocheinmal den 2.2 angeworfen und es sieht so aus, als hättest Du recht. Merkwürdig. Ich hatte mal irgendwas zu laufen, das mir eine schöne Liste angezeigt hat und ich hätte schwören können, das war ein älterer Xtreme. Und machbar müßte das ja auch sein; wenn das Muli bei a4a-Quellen entscheiden will, für welche Datei es sich bei mir anstellt muß es doch einen Überblick haben, was ich von welcher Datei anbiete. Dazu muß es mich fragen und ich weiß dann, was es von mir haben will.

Mit verwirrten Grüßen
aalerich

[drfreak2004]

würde ich ja gern aber da nur 19,5 kb erlaubt sind kann ich es net anhängen ohne das es bescheiden aussieht.

[aalerich]

Lads doch einfach zu Imageshack, Imagevenue oder Imagexoom hoch und hotlinke.

Mit freundlichen Grüßen
aalerich

[aalerich]

Zitat von Xman

- dynamic hide overshares: start with hideos=1, after 2/3 of the chunks are hidden, hideos will be increased

Um mal ehrlich zu sein: Ich verstehe nur Bahnhof.
Mein Verständnis: Bei powerreleasegesharten Dateien werden zunächst alle Chunks versteckt, sobald sie einmal hochgeladen wurden. (Kann ich mir nicht vorstellen, zumal ich keine Möglichkeit gefunden habe, das abzuschalten oder zumindest einen anderen Wert einzustellen.) Und was Hide OS "verstärkt" oder "gesteigert" bedeutet kann ich mir nicht mal in vagen Umrissen vorstellen.

Wild rätselnd und freundlich grüßend
aalerich

[Xman]

wenn 2/3 aller Chunks versteckt sind (da sie mehr als der Wert von HideOS [startwert 1]) wird HideOS soweit erhöht bis wieder weniger als 2/3 versteckt sind.

[aalerich]

Aha! Das habe ich jetzt verstanden. Was ich noch nicht verstanden habe: Ist das zwangsweise an Powerrelease geknüpft und wie stelle ich andere Werte ein?

Mit freundlichen Grüßen
aalerich

(Ehrlich gesagt schwant mir Übles. Ich befürchte, daß das fest miteinander verknüpft ist und der Startwert nur über die ini oder gar nicht verändert werden kann. Und wenn ich in einer Datei von 1,59 Gigabytes Größe und mit einer Chunkverteilung wie auf dem angehängten Bildchen zu sehen hochladen will werden seltene Chunks nicht häufiger hochgeladen als die, die kein Mensch wirklich braucht. Will ich also einen seltenen Chunk dreimal hochladen, muß ich einmal die komplette Datei, also 1,59 Gigabytes, einmal zwei Drittel der Datei, also 1,06 Gigabytes plus im Optimalfall mindestens noch diesen Chunk ein drittes Mal hochladen. Macht zusammen 2,65 GB. Eigentlich hätten auch 27,84 Megabytes ausgereicht. So verstehe ich das im Moment. Daß das auch so ist kann ich mir aber nicht vorstellen. Naja, ich warte mal ab, was Xman sagt. An und für sich finde ich Powerrelease ja sehr schön als Zwischenstufe zwischen Release und Powershare.)

[Xman]

1. Die Funktion ist ja zum Releasen da... und wie der Name schon sagt, bist Du somit der ziemlich einzige der die Datei vollständig hat.

2. es gibt ja noch etliche Ausnahmen
- da sich die Chunkverfügbarkeit im Netz ständig ändert, wird nicht abgespeichert wie oft welcher Chunk übertragen wurde(so wie bei allen anderen HideOS-Varianten). Es wäre nämlich falsch Chunks einen Monat später noch zu verstecken, nur weil sie vor einem Monat häufig hochgeladen wurden. Darum ist nach jedem Neustart des Xtremes, das HideOS quasi wieder jungfräulich.
- Du kannst niemals NNS(no needed patrs source) werden. Sind alle Chunks versteckt, die ein Client brauchen könnte, so wird für diesen Client kein Chunk versteckt udn er sieht die Datei vollständig.

[seppl12]

Zitat von aalerich

Will ich also einen seltenen Chunk dreimal hochladen, muß ich einmal die komplette Datei, also 1,59 Gigabytes, einmal zwei Drittel der Datei, also 1,06 Gigabytes plus im Optimalfall mindestens noch diesen Chunk ein drittes Mal hochladen. Macht zusammen 2,65 GB.

Ich mein, da hast einen Denkfehler drin.
Im ungünstigen Fall muß 1/3 des files hochladen werden (ohne Berücksichtigung des "no needed part source").

Angenommen du bist die einzige volle Quelle und drei Leute wollen das file. Irgendwann entstehen "seltenen Chunks", d.h., 1/3 der chunks ist noch nicht einmal verteilt (HideOS-count=1). Jetzt lädts du einen dieser chunks hoch, damit werden 2/3 der chunks, die bereits einmal verfügbar sind, versteckt. Also mußt im ungünstigsten Fall 1/3 der chunks hochladen, damit diese "seltenen Chunks" verschwinden. Ungünstigsten Fall deshalb, falls die drei user untereinander keine chunks austauschen. Und so gehts dann weiter mit HideOS-count=2 ...

[aalerich]

Naja gut, aber das mit dem Releasen ist in meinen Augen ja nicht nur das erstmalige Anbieten der Datei. Will ich in einer seltenen oder sehr schlecht verteilten Datei "zufüttern" bin ich ja in einer ähnlichen Situation.

Im Prinzip gut ist, daß das nicht gespeichert wird (Das auch noch zu speichern, zumindest länger als vielleicht zwei oder drei Tage, ist ja wohl der Gipfel der Dämlichkeit! Tschuldigung.) Allerdings ist das keine wirkliche Lösung. Im Grunde müßte ich dann nach jedem Upload des/der seltenen Chunks das Muli neu starten.

NNS zu werden ist nicht das Problem. Bei einer Datei von 9 Chunks sind zwei sehr selten. Ich lade die beiden hoch, vermutlich sogar gleich als ersten und zweiten. Dann werden sie versteckt. Der erste, der jetzt kommt (also der dritte, der von mir herunterladen will) braucht aber nicht nur diese beiden raren Chunks, sondern auch noch einen verbreiteteren. Und genau den zieht er von mir, die seltenen sind versteckt. Er hätte auch Glück haben können, nämlich dann, wenn ihm nur noch die beiden seltenen fehlen. Dann, aber eben auch nur dann, hätte er sie bekommen. Und nun laß' mich mal orakeln: der hat die Datei damit fertig und nimmt sie aus dem Share... Daher muß ich erst noch vier weitere Chunks hochladen (macht zusammen sechs, also zwei Drittel), obwohl die bei hunderten von Interessenten schon vorhanden sein können.

Soll ich Dir was sagen? Ich bin ein wenig enttäuscht. Gerade von Dir habe ich doch gelernt, daß es in der Regel sinnvoller ist, dem Herunterladenden die Chunkauswahl zu überlassen. Insbesondere dann, wenn er einen Mod mit Chunk Selection Patch verwendet. Es ist schon richtig, nicht immer ist das optimal. Aber sollte man dann nicht besser mit intelligentem Chunksharing arbeiten, statt mit dieser stumpfsinnig vor sich hin arbeitenden Funktion HideOS? Besonders schlimm finde ich, daß das an die Uploadpriorität geknüpft ist und ganz besonders schlimm ist, daß das von außen nicht zu sehen ist. Stell' Dir das doch mal vor: Da sitzt jemand, der nicht weiß, warum diese Kugel da unten gelb/grün ist und der mit Sicherheit gar nicht weiß, was ein Changelog ist. Auf dem Schulhof hat ihm jemand erzählt, daß man mit den Uploadprioritäten beeinflußt, welche Dateien wie stark hochgeladen werden. Was macht er also, wenn er mal von einer Datei mehr hochladen will, z.B. weil das Herunterladen wegen der schlechten Verteilung ewig gedauert hat? Richtig. Er versteckt Chunks und weiß es gar nicht...
Ich habe diese "Nebenwirkung" auch nur zufällig entdeckt; nie im Leben wäre ich auf die Idee gekommen, daß so etwas an eine unscheinbar klingende Uploadpriorität gebunden sein könnte.

@ seppl12:

Was Du meinst ist eben jenes intelligente Chunksharing. Diese Funktion steuert den Upload nach der Verfügbarkeit im Netzwerk. Hide Overshare zählt einfach, wie oft Du einen Chunk hochgeladen hast und blockiert ihn, wenn die eingestellte Anzahl an Uploads dieses Chunks erreicht ist. Steht Hide Overshare auf eins wird der Chunk nach einmaligem Hochladen versteckt. Basta. Es interessiert HideOS nicht, wie dieser Chunk verbreitet ist. Ganz genau das ist das Problem, diese Funktion ist ursprünglich so gut wie vollkommen intelligenzfrei und auch die Verbesserungen von Xman mildern die "Dummheit" dieser Funktion nur minimal. Sie arbeitet wohl in der übergroßen Mehrheit aller Fälle trotzdem noch so rücksichtslos und stur vor sich hin, daß sie mehr schadet als nutzt. Üblicherweise müßte ich die Datei einmal komplett hochladen um dem danach ersten Interessenten in meinem Upload wieder völlig freie Chunkauswahl anbieten zu können. Und wenn der dann diesen seltensten Chunk zieht haben nur noch die eine Chance, ihn von mir laden zu können, die nur noch diesen Chunk brauchen. Alle anderen müssen warten, bis ich den Rest der Datei einmal komplett hochgeladen habe. Der marginale Unterschied besteht nun im Xtreme darin, daß ich nur 2/3 der Datei relativ sinnlos hochladen muß um den seltenen wieder hochladen zu können.

Mit freundlichen Grüßen
aalerich

[Frawe]

@aalerich

Und wenn Du die Datei dann einfach nur auf Release stellst und den Rest auf niedrig? Dann sollte es doch Dein Problem nicht geben, da ja dann die Chunk-Selektion wieder Vorrang hat. Oder?

MfG Frawe

[Xman]

Die Datei einfach auf Release stellen ist genau der springende Punkt.
Es ist nicht imemr sinnvoll eine große, sehr seltene Datei rauszupauern. Erreichst Du, daß die 5 - 10 interessenten diese Datei innerhalb von wenigen Tagen komplett geladen haben, so ist die Wahrscheinlhckeit groß, daß diese Datei in 2 Wochen nicht mehr vorhanden ist. Vielleicht ist auch das der Grund warum der offizielle emule nur "normales" Release anbietet.
Bezüglich intelligentem Chunksharing:
Den Code für ICS hab ich mir noch nie angesehen. Soweit ich aber weiß übermittelt er nur, welche Chunks bei den anderen Quellen schon teilweise geladen wurden. Wie oft ein Chunk tatsächlich im Netzwerk ist kann man leider nicht rausfinden.
Für bestimmte Situationen mag das Powerrelease durchaus nicht vollens geeignet sein.. für diese Situationen hast Du aber wie gesagt das normale Release. Für das Releasen selbst ist Powerrelease zumindest aus meiner Sicht besser als manch andere Systeme geeignet.

Edit:
im übrigens: rechne Dein Beispiel nochmal durch... nehmen diese 2 Clients, die nun die Datei komplett haben die Datei aus dem Share, so ist die Wahrscheinlichkeit groß, daß der besagte rarste Chunk nun gar nicht mehr der Rarste ist.

[keven-b82]

Hallo!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

wo kann ich aktiven ich habe heuter angemeldet

[aalerich]

@Frawe:

Ja, im Prinzip schon richtig. Nur "verliere" ich damit die an sich ja sehr schöne zusätzliche Prioritätsstufe, was aber zugegebenermaßen nicht tragisch ist. Hauptproblem ist aber, daß wahrscheinlich nur wenige Prozent aller Xtremenutzer wissen, daß sie mit Powerrelease Chunks verstecken. (Und von denen, die es wissen sind sich wahrscheinlich nur die allerwenigsten über die Folgen wirklich im klaren.)

@Xman:

Jetzt bin ich endgültig verwirrt. Sich einen Überblick darüber zu verschaffen, wie oft ein Chunk im Netzwerk verfügbar ist, warum sollte das nicht gehen? Das ist doch genau das, was Dein Chunk Selection Patch macht. Beim Upload nur halt in die andere Richtung. Das ist doch das, was mir die Wasserstandsanzeige an Informationen gibt. Naja, jedenfalls aus meiner Warteschlange errechnet. Gebannte Klienten und vollständige Quellen sind da nicht mit eingerechnet. Bei gebannten Klienten ist das egal, vermutlich werde ich ja nicht der einzige sein, der sie gebannt hat. Deren Chunks sind also nicht wirklich verfügbar. Und die vollständigen Quellen haben ja zumindest auf die relative Seltenheit eines Chunkes verglichen mit anderen Chunks keinen Einfluß. Leider ist die Angabe der vollständigen Quellen im Dateifenster zwar da, aber so ungenau, daß sie nur zur groben Orientierung taugt. Aber der seltenste Chunk bleibt der seltenste Chunk, auch wenn noch zehntausend vollständige Quellen da sind.

Zitat von Xman

Es ist nicht imemr sinnvoll eine große, sehr seltene Datei rauszupauern.

Recht hast Du! Das Problem ist nur, daß wir beide das wissen, die überwältigende Masse aber nicht genug Verständnis der Zusammenhänge zu entwickeln vermag. Das Morph-Team beispielsweise ist bis auf den heutigen Tag überfordert damit, dieses Problem zu erkennen. Guten Willen möchte ich denen nicht absprechen, es mangelt offensichtlich an den nötigen geistigen Fähigkeiten. Wenn aber selbst die nicht in der Lage sind, solche Dinge zu verstehen, wie soll dann ein gewöhnlicher Durchschnittsnutzer das Problem begreifen?

Mein Vorschlag wäre, diese Verbindung von (des ja auf den ersten Blick nur als Prioritätsstufe erscheinenden) Powerrelease mit HideOS an- und abschaltbar zu machen (z.B. als Unterpunkt im Kontextmenü) und möglichst auch noch einstellbar, damit man eben auf Wunsch auch erst nach dem fünften Upload oder so beginnt, zu verstecken. Dadurch würde automatisch auch diese Aneinanderkoppelung offensichtlich werden. Wenn es denn sein muß kannst Du die Defaulteinstellung ja bei eins lassen, aber gib doch wenigstens denjenigen, die wissen, was sie da machen die Möglichkeit, korrigierend einzugreifen. (Schaden kann damit eigentlich niemand anrichten, die Einstellung eins ist ja schon der worst case. )

Zum Nachtrag:

Wenn zwei vollständige Quellen rausgehen kann der seltenste Chunk nicht häufiger werden, da kein Chunk häufiger entfernt wird.

Mit freundlichen Grüßen
aalerich

[seppl12]

Zitat von aalerich

@ seppl12:

Was Du meinst ist eben jenes intelligente Chunksharing. Diese Funktion steuert den Upload nach der Verfügbarkeit im Netzwerk. Hide Overshare zählt einfach, wie oft Du einen Chunk hochgeladen hast und blockiert ihn, wenn die eingestellte Anzahl an Uploads dieses Chunks erreicht ist. Steht Hide Overshare auf eins wird der Chunk nach einmaligem Hochladen versteckt. Basta. Es interessiert HideOS nicht, wie dieser Chunk verbreitet ist. Ganz genau das ist das Problem, diese Funktion ist ursprünglich so gut wie vollkommen intelligenzfrei ...

Dachte bisher, das Xman's intelligentes HideOS genau so arbeiten, das es sich an der Verfügbarkeit der chunks orientiert. Wenn es so nicht ist, wo bleibt da die "Intelligenz"? Es ist ja dann, wie du sagst, eher kontraproduktiv.
Xman, man kenne doch die Chunkverteilung eines files für jene clients in der Queue. Anhand dieser Verteilung müßte sich doch eine intelligente Uploadregelung der chunks implementieren lassen.

[Xman]

die Chunkverteilung in der Uploadqueue läßt sich erahnen aber nicht 100% bestimmen.
da 1.) nicht jeder Client der das File lädt sich auch bei Dir anstellt.
2.) z.b. von Hybriden bekommst Du gar keine Information, welche Chunks diese bereits haben
3.) wie schon angemerkt, werden vollständige Quellen hier nicht erfaßt.