[LastHopper]

Ich hätte einen kleinen Wunsch an die Macher des eMules, der sich leicht bewerkstelligen ließe.

Es kommt nicht häufig vor, aber doch hin und wieder. Der DL eines Dateiteils wird abgebrochen, weil die maximale Zeit nämlich eine Stunde abgelaufen ist. Es fehlten allerdings nur noch wenige Sekunden, dann wäre der ganze Teil der 9,28 MB komplett gewesen. Und manchmal wäre auch ein kompletter Download fertig gewesen.

Diese Tatsache ist recht unpraktisch, weil man dann unter Umständen noch eine lange Zeit warten muss, bis ein paar wenige Bytes abgearbeitet sind.

Mein Vorschlag wäre, diese Stunde nicht ganz so eng zu sehen und bei Ablauf eine kleine Prüfroutine einzufügen. Sind zB noch weniger als 100 kb notwendig um einen Dateiteil zu vervollständigen, dann wird der auch noch erledigt - egal ob die Stunde vorbei ist.

Gruß LH

[Link64]

Bin auch dafür!!!

[TheRunner]

ich hab solch ein problem immer mit 300kb welches ja der chunk size im chunk ist sprich mein mule den clients nicht sagen kann gib mir diesen teil. nämlich wenn er das versucht hören die anderen clients auf zu übertragen. leider haben das auch viele modder verschuldet wenn man sich deren features ansieht.

[schmu]

sowas lässt sich zuleicht missbrauchen, da erzähl ich dem anderen halt immer mir fehlen noch diese und jene 300kb dann habs ichs komplett und der schickt mir dann immer fleissig alles rüber ?

[Staubpartikel]

schmu, on Feb 17 2004, 02:58 AM, said:

sowas lässt sich zuleicht missbrauchen, da erzähl ich dem anderen halt immer mir fehlen noch diese und jene 300kb dann habs ichs komplett und der schickt mir dann immer fleissig alles rüber ?

Nicht unbedingt da es ja auf 1 Anfrage pro Chunk etc beschränkbar wäre,allerdings wäre es schon sehr aufwendig und Ressourcen fressend so eine Anfrage sicher zumachen...


@LastHopper & ALL
Was mich interessiert ist die Frage,seit wann und in welcher Version ist das so und wo steht das,dass nach 1h der Download gecancelt wird und das passiert auch wenn bei Einstellungen/Dateien"Versuche komplette Chunks hochzuladen"an ist?

This post has been edited by Staubpartikel: 18 February 2004 - 01:55 AM

[JAW]

Wieso wäre das aufwändig?
Momentan prüft Emule
1) ob der Upload schon länger als 1 Stunde läuft
2a) ohne Full Chunk Upload, ob ein anderer Client mehr Wartepunkte hat
2b) mit Full Chunk Upload, ob schon ein ganzer Chunk hochgeladen wurde.
Trifft eines davon zu, wird der Upload beendet.

Streicht man die Abfrage der Uploadzeit, müssten Uploads also immernoch aufgrund der 2. Bedingung beendet werden und keiner ewig nen Slot halten. Falls bei 2a) diesbezüglich doch Gefahr besteht: Was ist eigentlich der Grund, warum Full Chunk Upload abschaltbar ist?

[prototyp]

was macht ihr für aufstände?

am einfachsten gehts doch so, ohne mehr traffic overhead.

nach 1er stunde schaut emule wie viel das es bei client x raufgeladen hat. beispiel

nach 59 min sind 6.5 megs raufgeladen = bei 60 min cancel
nach 59 min sind 9.7 megs raufgeladen = weiter laden bis man ganzes chunk raufgeladen ist, nach 9.83 megs (einem chuck) wird dann automatisch gecancelt.

am besten wäre es wenn man noch einbauen würde das er auf die durchschnitts/aktuelle geschwindikeit achtet. ich meine wenn ein ul bei 9.7 steht und transferrate ist 0. warum nicht canceln?

wäre etwas für die features request

[blutfaust]

prototyp, on Feb 18 2004, 05:59 PM, said:

was macht ihr für aufstände?

am einfachsten gehts doch so, ohne mehr traffic overhead.

nach 1er stunde schaut emule wie viel das es bei client x raufgeladen hat. beispiel

nach 59 min sind 6.5 megs raufgeladen = bei 60 min cancel
nach 59 min sind 9.7 megs raufgeladen = weiter laden bis man ganzes chunk raufgeladen ist, nach 9.83 megs (einem chuck) wird dann automatisch gecancelt.

am besten wäre es wenn man noch einbauen würde das er auf die durchschnitts/aktuelle geschwindikeit achtet. ich meine wenn ein ul bei 9.7 steht und transferrate ist 0. warum nicht canceln?

wäre etwas für die features request

So wie du das beschreibst wäre es glaube ich machbar und auch sinnvoll. Das macht richtig Sinn.


Wer kann das ins Feature Request posten? Mein Englisch ist leider nicht ausreichend.

[prototyp]

blutfaust, on Feb 18 2004, 11:02 PM, said:

Wer kann das ins Feature Request posten? Mein Englisch ist leider nicht ausreichend.

meins ist auch nicht so gut

darum wäre ich froh wenn das jemand ins feature request übersetzen kann.

[TheRunner]

schreibt doch ornis eine pm der kann euch auch bestimmt gleich schon mal ne antwort geben für wie wichtig er das hält.

[prototyp]

ich schätze im feature request forum ists besser aufgehoben, weill da auch verschiedene mod schreiber sich rumtumeln, und für die wäre das sicher ein gefundenes fressen, da sie dann ein feature mehr hätten

[TheRunner]

jup es gab ja auch schon des öfteren feature request auf deutsch mit dem vermerk das man eben nicht sehr gut englisch kann.

[Devil Doll]

Ich könnte den Feature Request posten...

...aber er überzeugt mich nicht. Wenn der Abnehmer langsam ist, dann lade ich lieber anderen Clients hoch, die vernünftiger mit mir kommunizieren.

Wenn nämlich mehrere Abnehmer gleichzeitig langsam sind, dann dauert die Upload-Bandbreiten-Balance von Emule auf die anderen Clients erst mal eine Weile, und in dieser Zeit geht mir Upload-Leistung verloren.
Ich halte es für richtig, langsame Downloader aus den Slots zu kicken - das gesamte Netz profitiert IMHO letzten Endes davon, daß ich meinen Upload möglichst voll ausnutzen kann.

Falls dieser Fall für einen Uploader öfters vorkommt, sollte dieser mal überlegen, ob sein Gleichgewicht zwischen Slots und freigegebener Upload-Bandbreite stimmt.
Wenn man weniger hoch lädt, dann gibt man dem Netz nicht nur weniger, sondern (noch deutlicher) weniger vollständige Chunks. Mit 10 kB/sec bei deutschen ADSL ist die Wahrscheinlichkeit für dieses Ereignis einfach höher als mit 13 kb/sec (die ich seit Monaten erfolgreich und ohne Download-Beschränkung fahre).

Also: Lieber Aufklärung an die Uploader, als eine Programmändernung, die IMHO wenig bewirkt. Irgendwo ist nun mal die Grenze - was bringt es, diese zu verschieben? Dann wären eben andere Clients unglücklich...

Und ja, auch ich frage mich, wieso man den "full chunk upload" abschalten kann. Oder das Creditsystem. Die Antwort lautet vermutlich: "Weil es irgend jemand wollte, und weil es ansonsten ein Mod eingebaut hätte"...

This post has been edited by Devil Doll: 19 February 2004 - 10:41 PM

[LastHopper]

Divil Doll - das ist ein echter Troll-Beitrag, der zeigt, dass Du nichts verstanden hast.

LH

[prototyp]

also nochmal für die wo noch nicht ganz schlau geworden sind.

wie es jetzt ist:

bei full chunk upload läd man (versucht es) dem andern clienten genau 1 chunk rauf. das geht folgender masen. man läd so lange rauf bis der andere client eine meldung schickt, das er ein anderes chunk braucht. was "deinem" emule signalisiert das du ihm ein ganzes chunk oder ein angefangenes fertig raufgeladen hast. das problem ist das der ul automatisch nach 1 h gecancelt wird. nicht das leute bei 0.3 kb ul stundenlang in der upload queue stehen.

jetzt das problem:

wenn jemand einem probiert ein chunk raufläd, jedoch z.b. mit 2.6 kb raufläd, hat man nach 1ner stunde genau 9.36 mb erhalten. und da er automatisch cancelt, hat man kein volles chunk und kann das somit auch nicht sharen, weill etwa 400 k fehlen. das heist theoretsch das du von einem 400k bekommst und der dl abgebrochen wird, weil das chunk fertig ist. jedoch bekommt man für 400 k keine credits, somit bring es nichts, auser länger warten in der queue.

nun der verbesserungs vorschlag:

man läd normal rauf, dann aber nach 59 min wird geprüft wie viel man noch dem clienten raufladen muss, das heist wenn emule merkt das man noch xxx k raufladen muss läd es weiter noch etwa (bei 400 k) 2-3 min weiter bis man ein chunk hat. jedoch wenn emule nach 59 min merkt das man erst 6.5 megs raufgeladen hat, wird der ul automatisch gecancelt bei 60 min.

vorteil:
- man hat schneller ein ganzes chunk = man kann dies weitersharen, was bei releasen recht hilfreich ist.
- es gibt nicht mehr traffic overhead, das nichts zusätzliches verschickt wird.
- man steht nicht mehr viel in queues die einem 400 k raufladen, und man somit zeit "verdummt".

nachteil:
- minim mehr rechner leistung, jedoch wirklich minim

hoffe ich konnte damit einigen helfen die nicht drausgekommen sind

This post has been edited by prototyp: 20 February 2004 - 05:29 PM

[blutfaust]

Exakt so hatte ich es auch verstanden.

Was mich jedoch irritiert: Du sprichst immer von 9,83 MB-Chunks. Ich dachte die Chunk-Grösse wäre 9,28 MB. Oder wurde das geändert und ich habe es irgendwo überlesen?

[blutfaust]

Ich habe es jetzt mal ins Feature Request gepostet.

http://forum.emule-p...=ST&f=6&t=40360

Ich hoffe nur, daß die englischsprachigen mich auch verstehen...

Gruß,
Blutfaust

[prototyp]

blutfaust, on Feb 21 2004, 12:45 AM, said:

Du sprichst immer von 9,83 MB-Chunks. Ich dachte die Chunk-Grösse wäre 9,28 MB.

merke gerade das ich mich geirrt habe

war mein fehler (man sollte nicht einfach so drauf los schreiben), aber ich denke ob nun 9.83 oder 9.28, den sin des posts haben hoffe ich alle verstanden

[Devil Doll]

Quote

jedoch bekommt man für 400 k keine credits, somit bring es nichts, auser länger warten in der queue.

Seit wann bekommt man für 400 K keine Credits? Für die ersten 400 K bekommst Du keine sofort nutzbaren Credits - aber wer sagt Dir, daß es die ersten sind und die letzten bleiben werden (nur dann stimmt diese Argumentation)? In der Liste meiner Besucher stehen sehr wohl Clients mit weniger als 400 kB - die haben zwar noch einen Faktor von 1.0, aber sie haben sehr wohl bereits Credits, wofür müßte man diesen Wert sonst speichern?

Und nach welchem Kriterium wird bemessen, daß es "knapp zu wenig ist"?
Wird bei 9.26 MB verlängert? Bei 9.24 MB? Bei 9.18 MB? Wo ist die Grenze, und warum ist knapp weniger nicht auch noch sinnvoll? Wo ist die zeitliche Obergrenze, nach welcher dann doch abgebrochen wird? Bei 65 Minuten? 70? 77:30?

Und nein, ich habe nicht vor, zu trollen - ich halte bloß die Idee nicht für überzeugend. (Mir fehlt der Algorithmus, der das "nicht ganz so eng sehen" quantifiziert.)
Aber da sie als Feature Request gepostet ist, laßt uns abwarten, was passiert...

This post has been edited by Devil Doll: 21 February 2004 - 01:17 AM

[NOCKIPOCK(German)]

Also ich finde das ist eine sehr gute Idee, ich hoffe das wir in eMule Integriert.