Download schneller nach Servertrennung?

[Slider63]

Guten.
Ich bin zwar kein Neuling mit eMule mehr aber neuerdings habe ich da was, das ich gar nicht verstehe.
Mein Download steigt rapide an, wenn ich mich von einem Server trenne. Er braucht dann ein paar Minuten und steigt stetig an bis das aktuelle Maximum an Speed erreicht ist. Also nicht volle Kanne, sondern soviel wie die aktuellen Downloads das hergeben. Verbinde ich mich dann wieder mit einem Server geht der Speed wieder in den Keller. Wenn ich dann wieder trenne geht das Spiel von vorne los.
Ich habe weder die Grenze zu sharender Files bei den Servern erreicht noch lade ich alten Müll runter. Es ist einfach so, dass meine Downloadgeschwindigkeit steigt sobald ich nicht mehr mit einem Server verbunden bin. Ich nutze momentan den eMule V0.28b Morphv6b. Diese Phänomen habe ich schon seit einigen Versionen. Am Betriebssystem kann es nicht liegen, das ist schon 2 mal erneuert worden. Ach ja, im Download befinden sich grade 70 Files, im Share 220.
Hab es mit der Suchenfunktion schon versucht aber nichts passendes gefunden.
greetings

slider

[derjaumer]

ich würd sagen dein hard limit ist zu hoch, deswegen sucht er sofort viele neue Quellen anstatt zu saugen. Setz das mal auf 400, dann müsste das gehn

axo, der download wird dann nach einigen MB abbrechen weil er alle vorhandenen Quellen genutzt hat und keine neuen mehr bekommt

[Shaolin®]

bei mir spüre ich nix von einer speed erhöhung

[Slider63]

Guten.
Also, ich habe diese komische Sache immer noch. Server getrennt, Download rauf, Server verbunden, Download runter. Komisch ist auch, dass sich der Download meistens bei 10kb einpendelt.
Ich habe DSL, 12 Up und 96 Down eingestellt, 200 Quellen, 500 max Verbindungen, alle 5 Sek 20 Verbindungen aufbauen. Laufe auf WinXP.
Was kann das wohl sein? Hab echt kein schnall mehr. Besonders, weil der sonst immer so gut lief, mit Raten von 40kb und mehr.

[cyberion]

Hallo,

ich benutz den akt. sivka und habe ca. die selbe ausgangslage was shared files angeht im dlliegen bei mir auch ca 200. Und ich stell dasselbe Phänomen fest! Servertrennung dl hoch ... und up auch 10kb musste den up auf 10kb limit stellen und nu geht der dl auch wieder besser ...

max. quellen: 200
max verb. 500
v/5sec 30

Würde mich auch interessieren warum das so ist! Kann das einer erklären?

bye, cyberion

[Anonymous]

unter anderem weil dann der traffic zum server wegfällt. allerdings wird der hohe dl nicht allzulange anhalten, weil keine neuen quellen mehr nachkommen.

[tiger]

Versteh das nicht wirklich so komplett, aber es scheint doch als ob der Up schlicht zu hoch war. Für den Overhead blieb nix mehr übrig, bzw. mit war der up auf Anschlag und drüber. - Das blockiert dann halt den DL.

[Slider63]

Tja, ist ja schön, dass ich wenigstens nicht alleine so ein doofes Problem habe. Ich werde meinen Upload auch mal begrenzen und hoffen, dass sich was bessert.
Als Upload hab ich 11kb eingestellt und wenn ich im Durchschnitt(ermittelt durch hinschauen) einen Overhead von 1-2 kb habe, wieso sollte ich dann schon den Download blockieren? Das peil ich nicht.

[Slider63]

Faszinierend! Ich habe den Upload auf 10kb begrenzt und schon juckt es den Esel und er rennt mit 20kb-30kb mehr. Und das schon noch einer halben Stunde. Nach der Umstellung ging der Download augenblicklich in die Höhe und bleibt scheinbar da. Sehr schön.

Besten Dank erstmal und Daumen drücken, dass es so bleibt.
greetings

slider

[Blomy]

@ Slider63
mal ein Rechenbeispiel :
10 Files im DL mit 300 Quellen = 3000 Anfragen (selbst einige Files geshared)
Irgendwie muss Emule diese 3000 Quellen verwalten, nachschauen ob ein Client noch vorhanden usw. Und dies geschieht über den UL Slot. Darüber wird auch der DL verwaltet, zwecks anfragen etc. Dabei schnellen die aktiven Verbindungen in die Höhe und Emule ist nur noch mit dem Nachfragen beschäftigt und hat keine Zeit mehr für den DL.
Ich habe es ausprobiert und festgestellt, das man nicht über 3500 - bis 4000 Quellen gehen sollte. Die Anzahl der Files im DL ist dann egal. Bei 70 Files im DL also max. Hardlimit pro File auf 50-60. Bei max HL 300 und 70 Files = 21.000 Quellen. Wie soll Emule da noch Zeit finden, sich um den DL zu kümmern. Keine Chance.
Also xxx Files im DL + xxx Hardlimit pro File = max. 3000 - 4000 Quellen insgesamt.
Und du kannst den UL auf ca. 11-14 stellen. Je weniger Quellen insgesamt zu verwalten sind, um so höher der UL/DL. (Von Fall zu Fall unterschiedlich)
Es hilft also nicht den UL zu begrenzen, sondern die max. Quellen richtig einzustellen.

Dann funktioniert das Surfen im Netz usw. auch noch.
Alles Werte für W2K + Win XP. --- Win98 ist leider eine Krücke.

[Slider63]

@blomy: Vielen Dank für die gute Aufschlüsselung dieser Funktionsweise. Jetzt verstehe ich, wieso ich ständig solche Probleme hatte. In der Tat ist der Download insgesamt gestiegen seitdem ich die relevanten Werte etwas nach unten korrigiert habe. Hehe, schön das Mathe doch noch zu was taugt.

[tiger]

Zitat von Slider63

Tja, ist ja schön, dass ich wenigstens nicht alleine so ein doofes Problem habe. Ich werde meinen Upload auch mal begrenzen und hoffen, dass sich was bessert.
Als Upload hab ich 11kb eingestellt und wenn ich im Durchschnitt(ermittelt durch hinschauen) einen Overhead von 1-2 kb habe, wieso sollte ich dann schon den Download blockieren? Das peil ich nicht.

k.a. was da an overhead angeben ist in den Stats. Du benötigs bandbreite zum Server und zu den andernen Klienten. Und das sind jeweile 1-3 k - im dümmsten Fall also 6 k - womit für den Up noch 10 bleiben. Wenn du nen Mod mot AUM/SUC hast, einfach mal auf 7/12 stellen, und abwarten. was passiert. cFos kann durch Traffic-Shaping auch genz nützlich sein, kost aber ein paar Euro.

Zitat von www.cfos.de/techinfo/shape.htm

Beim TCP/IP Datenverkehr muss der Empfang einer bestimmten Menge an Daten von der Gegenseite bestätigt werden, bevor der Sender neue Daten versenden darf. Kommen diese Empfangsbestätigungen nicht schnell genug, muss der Sender warten und es kommt zu Verzögerungen und Einbrüchen der Transferrate. Gerade bei ADSL kann es passieren, dass man einen Download ausbremst, indem man den Rückkanal (der ohnehin die kleinere Bandbreite hat) mit einem Upload verstopft, so dass nicht mehr genügend Bandbreite für die Empfangsbestätigungen des Downloads zur Verfügung steht. Verzögerungen innerhalb der DSL-Strecke tun ihr übriges, so dass durch Uploads die Transferrate der Downloads einbricht (Bild A).

Um diesen Effekt zu kompensieren, erhöhen einige DSL-Treiber bzw. Tuning-Programme die TCP Window-Size, so dass der Sender mehr Daten verschicken darf, bevor er auf eine Empfangsbestätigung warten muss. Dieser Vorteil wird aber durch eine deutliche Erhöhung der Latenz (Ping-Zeiten) erkauft, so dass das Surfen während eines Datentransfers ungewöhnlich langsam ist (Bild B). Wir haben zudem nachgemessen und festgestellt, dass TCP Window-Size Werte über 64k sowieso "nichts mehr bringen", d.h. trotz riesiger Windows kommt man nicht auf den vollen Datendurchsatz.

Das cFos Traffic Shaping analysiert nun den anfallenden Datenverkehr in beide Richtungen und priorisiert die Datenpakete so, dass Uploads die DSL-Strecke nicht mehr verstopfen und Downloads sich nicht gegenseitig ausbremsen.