Fehler: Download session disconnect error 10053

littletiga · 6. November 2006, 15:45

wenn du mir sagst wie ich das hier poste.............

so, hier is es.

das is auch ein gutes beispiel. Das ist meistens kein Browserverkehr oder sonstiges. Ich hatte auch schon zum test den browser und alle anderen anwendungen geschlossen.
Das resultiert fast immer daraus, wenn ein user im upload ist, der socket-blockierverhältnisse verursacht. es ist auch meistens immer nur einer.

[Screenshots entfernt, da IP-Adressen anderer Clients zu sehen waren]

**Xman** · 7. November 2006, 08:57

ok.. habs mir angesehen und möchte darauf antworten:

Zitat:

Jetzt bekomm ich nur noch socket-abbrüche im download wenn im upload ein user ist, der egal wieviel Prozent, Blockierverhältnisse hat. Denn dann hält das nafc den upload nicht mehr konstant und schlägt ab und zu aus bis über die leitungsgrenze. Deswegen hab ich als socketabbrüche im download.

Hat da jemand ne lösung für?

die Socketabbrüche haben damit nichts zu tun. Socketabbrüche sind ziemlich normal. Schau Dir mal meine Statistik an:

eMule v0.47c Xtreme 5.3.1 Statistics
Download Sessions: 3567
Successful Download Sessions: 3146 (88.2%) (active: 31, paused: 2, no needed part: 183, timeout: 619, socket: 746, out of part: 1565, exception: 0, others: 0)
Failed Download Sessions: 421 (11.8%) (paused: 0, no needed part: 19, timeout: 114, socket: 282, out of part: 6, exception: 0, others: 0)
Average Downloaded Per Session: 5.54 MB
Average Download Time: 26:23 Minutes

Out of Part sind normal abgeschlossene Downloads. Socket und Timeout bedeuten, daß der Socket wie auch immer "gestorben" ist.

NAFC reguliert übrigens nicht falsch, bzw. über die Leitungsgrenze... Du hast vielmehr eine hohe Auflösung des Statistikgraphen mit dem Du jede Schwachstelle des Systems siehst. Und hier muß ich die Einstellung zum Socket-Send-Buffer ins Spiel bringen:
emule schiebt die Daten nur in diesen Buffer, wann sie letztendlich tatsächlich gesendet werden entscheidet Windows ganz alleine. Ist dieser Buffer also groß (12 kb) und Du hast einen Uploadslot mit hohem Blockierverhältnis, dann schickt Windows diese 12 kb Daten *irgendwann*. Darum gibts auch diese Spitze in Deinem Upload. NAFC merkt erst ein paar Millisekunden später: "moment da sind grad zu viele Daten geflossen, dann sende ich die nächsten xxx Millisekunden mal nichts mehr".
Mit einem kleinerem Sendebuffer reduzierst Du diesen Effekt. Stellst Du den Statistikgraphen auf 5 oder mehr Sekunden wirst Du diesen Effekt auch weniger sehen.
Der offi client hat dieses "Problem", daß eben bei blockierenden Sockets der Upload schwankt wesentlich stärker. Dadurch, daß er den Graphen aber extrem glättet wirst Du es dort gar nicht sehen.

**seppl12** · 7. November 2006, 09:27

Zitat:

Zitat von littletiga

also, hab mein problem jetzt minimiert.
Das heisst, ich habe die MTU im xtreme auf 1000 gesetzt und doppelte sendegrösse aus gemacht.
Dadurch konnte nafc den upload erheblich besser stabil halten.

Ich weis nicht woher du diesen Wert hast (empirisch geraten?), aber kein BS und TCP/IP Protokoll unterstützen das. Führt nur daszu, das deine gesendeten Daten "ungünstig" gesplittet werden (erhöht den overhead).

Jetzt hoffen wir mal, das das der einzige Wert ist, den du in der Registry "verpfuscht" hast und auch kein sonstiges sogenanntes "Optimierungstool für die Registry" verwendet hast, die verschlimmbessern die Sache immer nur. Stell den MTU Wert in der Registry wieder auf seine default Wert von 1492 (Rechner rebboot). Und dann kannst du anhand der Beschreibung hier: Bei DSL-Verbindung einen Router optimalen MTU-Wert ermitteln und über die Registry einstellen. deinen MTU Wert ermitteln und in eMule setzten (evtl. auch im Router anpassen).

Oben hatte ich dich gefragt, ob noch irgendeine firewall bei dir läuft und ob du jegliche AMV Software deinstalliert hast ... leider erfolglos.

Anhand deines ersten Screenshots kann man erkennen, das deine Fritzbox mit den vielen Verbindungen nicht zurechtkommt und anhand der anderen beiden screenshots, das womöglich dein Upload zu hoch eingestellt ist (keine Reseven bei providerseitigen
Schwankungen).

Mein Vorschlag, den du mal testen könntest, NAVC deaktivieren und ein festes Upload Limit von 16 kB/s einstelln. Den Wert für Max.Verbindungen auf 200 und den Wert für Verbindungen pro 5 sec auf 20. Und nicht mehr als 2500 Gesamtquellen im eMule haben.

Wärte schön, wenn du uns mit diesen Werten einen Screenshot zeigen könntest.

littletiga · 7. November 2006, 15:06

@xman
wenn du den sendepuffer vom xtreme meinst, so hab ich den schon die ganze zeit auf 6000 stehen. Ansonsten klär mich bitte auf, wie ich den in windows verstelle. Die hohe auflösung des statsgraphen hab ich extra so gemacht, das ich mögliche fehler sehen kann. War also absicht.Wll den graphen nicht höher stellen, da ich die fehler beseitigen will und sie nicht verdecken möchte.

@seppl
Das Betriebssystem muss die niedrige mtu auf jeden fall unterstützen, denn wenn du mit einem modem surfen tust, ist ne mtu von 500 ganz normal. und der xtreme unterstützt dies auch, da dadurch die schwankungen enorm weniger geworden sind. Es sind aber ca. 0,5 kb overhead mehr geworden.
Alles unter 1000 mtu frisst er erheblich mehr overhead, sodass dieses verhältniss nicht mehr stimmt. deswegen 1000. Und verpfuscht hab ich auch nix, es war nur ein versuch. Ich kenne mich sehr wohl mit diesen werten aus und ziemlich vieles andere was pc betrifft auch. <--kein neuling...........
firewalls hatte ich alle schon deinstalliert, auch die windowsfirewall aus usw. also ich hab wirklich alles probiert. Ich hab mittlerweile die fritzbox 7170 bekommen und die verträgt so viele verbindungen wie du sie nie aufbauen würdest. Das weiss ich weil sie im emule schon auf über 1200 verbindungen gelaufen ist.
90% des uploads is bei mir 21.6 kb/s. Ich habe auf 21 kb/s eingestellt. also puffer genug. Die schwankungen Providerseitig sind tagsüber max. 2 kb/s. Wobei man bedenken muss, das ich bei meinem dsl 2000 noch den overhead zur leitung mitbekommen hab. also hab ich einen upload von 203.
Ich möchte nafc nicht deaktivieren, weil ich dann genausoweit wäre wie vorher. ich finde das es ein sehr gutes werkzeug ist, um den upload möglich hoch zu halten. Ich möchte nur, das alles möglichst fehlerfrei läuft.

Ps: das ich das mit der firewall nicht beantwortet hab, tut mir leid. habs wohl übersehen oder so.

**seppl12** · 7. November 2006, 16:54

Zitat:

Zitat von littletiga

Das Betriebssystem muss die niedrige mtu auf jeden fall unterstützen, denn wenn du mit einem modem surfen tust, ist ne mtu von 500 ganz normal. und der xtreme unterstützt dies auch, da dadurch die schwankungen enorm weniger geworden sind. Es sind aber ca. 0,5 kb overhead mehr geworden.
Alles unter 1000 mtu frisst er erheblich mehr overhead, sodass dieses verhältniss nicht mehr stimmt. deswegen 1000.

Richtig! Bei Tunnelprotokollen, wie bei DSL typischen PPPoE, wären prinzipiell alle Werte unter 1492 einstellbar. Diesen Wert braucht man im BS nur verstellen, wenn man mit seinem Provider Probleme hat, http Seiten zu öffnen. Planloses verändern der MTU im BS und im Xtreme, und da auch noch unterschiedlich, führt i.a. zwangsläufig zur Erhöhung des Overheads. Daher mein Vorschlag, dein Upload Limit fest und niedriger einzustellen ... war nur ein Vorschlag fürs testen.

Zitat:

Zitat von littletiga

Ich hab mittlerweile die fritzbox 7170 bekommen und die verträgt so viele verbindungen wie du sie nie aufbauen würdest. Das weiss ich weil sie im emule schon auf über 1200 verbindungen gelaufen ist.

Ja, laufen schon, aber mit den von dir beschriebenen Symptomen ... was dein erster Screenshot zu 100 % bestätigt. Daher mein Vorschlag für die Verbindungseinstellungen ... war nur ein Vorschlag fürs testen.

Zitat:

Zitat von littletiga

90% des uploads is bei mir 21.6 kb/s. Ich habe auf 21 kb/s eingestellt. also puffer genug. Die schwankungen Providerseitig sind tagsüber max. 2 kb/s. Wobei man bedenken muss, das ich bei meinem dsl 2000 noch den overhead zur leitung mitbekommen hab. also hab ich einen upload von 203.

Mein Provider hat mir einen 600 kbit Upload verkauft ... tatsächlich schwankt die Bandbreite zwischen 450 kbit und 520 kbit ... und das in nächster Nachbarschaft zum Knotenpunkt. Daher mein Vorschlag, dein Upload Limit fest und niedriger einzustellen ... wie gesagt, war nur ein Vorschlag fürs testen.

Zitat:

Zitat von littletiga

Ich möchte nafc nicht deaktivieren, weil ich dann genausoweit wäre wie vorher. ich finde das es ein sehr gutes werkzeug ist, um den upload möglich hoch zu halten. Ich möchte nur, das alles möglichst fehlerfrei läuft.

Inwieweit die Nutzung von NAFC bei der Verwendung eines Routers Sinn macht, muß jeder für sich selbst entscheiden. Ob bei dir noch andere Rechner mit Bandbreitenverbrauch am Router hängen, spielt da sicher eine entscheidende Rolle. Daher mein Vorschlag, NAFC zu deaktivieren ... wie gesagt, war nur ein Vorschlag fürs testen.

edit/

Zitat:

Zitat von littletiga

Ps: das ich das mit der firewall nicht beantwortet hab, tut mir leid. habs wohl übersehen oder so.

Und was ist mit der Fritzsoftware ...

littletiga · 7. November 2006, 18:19

fritzsoftware war auch schon komplett deinstalliert. Bei meinem 1.screenshot wurde der xtreme grad gestartet und hat quellen aufgebaut. ich habe 50 per 5 und 100 halboffene. das mit dem uploadlimit hab ich schon gemacht. hat aber an den sockets nichts geändert. hatte auch schon ein modem dran und der upload sah ganz genau so aus.

**Xman** · 7. November 2006, 19:48

wegen der MTU möchte ich noch bemerken:
klar wird die Linie schöner je kleiner die MTU ist... denn eine Straße läßt sich mit kleinen Steinen viel ebener bedecken als wenn ich Felsbrocken nimm. Ein bischen Zickzack ist also durchaus normal. Höhere MTU = weniger Overhead.. zu hohe MTU ist aber wieder erhöhter Overhead, darum verwendet der offi Emule den Wert 1340. 1440 sollten aber bei jedem deutschen DSL-Anbieter drin sein.

littletiga · 7. November 2006, 20:50

@xman
kann man was an dem sendepuffer in xp ändern?

**seppl12** · 7. November 2006, 23:22

Zitat:

Zitat von littletiga

fritzsoftware war auch schon komplett deinstalliert. Bei meinem 1.screenshot wurde der xtreme grad gestartet und hat quellen aufgebaut. ich habe 50 per 5 und 100 halboffene. das mit dem uploadlimit hab ich schon gemacht. hat aber an den sockets nichts geändert. hatte auch schon ein modem dran und der upload sah ganz genau so aus.

Ich benutzte auch einen Router und fahre den auch mit 50 neue Verbindungen pro 5 sec mit dem Unterschied, das mein Router da mitspielt ... hab dir einen Screenshot angehängt mit meiner Uploadkurve und den aktiven Verbindungen. Man sieht die Zwangstrennung, was aufgrund des "Reask aller Quellen nach IP Wechsel" auf das gleiche rauskommt, wie ein Neustart ... und ich seh bei mir keine deutlichen Uploadschwankungen.

Und über 50 % Socketabbrüche in den fehlgeschlagenen Up- und Downloads sind ganz normal, da änderst du, ich oder Xman nichts daran, egal mit welchen Einstellungen.

**Xman** · 7. November 2006, 23:26

Zitat:

Und über 50 % Socketabbrüche in den fehlgeschlagenen Up- und Downloads sind ganz normal, da änderst du, ich oder Xman nichts daran, egal mit welchen Einstellungen

so isses (leider). Hatte gehofft, daß sich mit Obfuscation hier eine deutliche Verbesserung abzeichnet.. aber nix da.

@littletiga
nee. Windows benutzt eine Standardvorgabe von 8192 die der Xtreme Programmtechnisch verändern kann.

littletiga · 7. November 2006, 23:28

ja sicher. du hast ja auch 40 sekunden updateintervall, ich hab grad mal 1 sekunde.
Starte mal deinen esel neu und mach 1 sekunde intervall. dann würde ich das gern nochmal sehen.

dann hat sich das auch eigentlich erledigt.
Ich dachte das da ein fehler vorliegt.
Möchte nur gern wissen durch was diese abbrüche kommen. liegts allgemein am emule oder an der leitung?

Ähnliche Themen: Fehler: Download session disconnect error 10053