eWombat 0.063 kontra 0.29c LSD10c Anfrage vorhandener Parts

[Blomy]

Seit ca. 1 Woche sauge ich beim eWombat 2 Files mit ingesamt 34 Quellen.
Laut Dateistatiistik wurde in dieser Zeit 15 (21) nach diesen Files
gefragt und auch dementsprechend UL gegeben.

Jetzt habe ich so ca. um 15:30 Uhr den LSD 10c paralell am laufen
mit diesen Files.(beim Wombat stehen sie jetzt auf STOP)
Innerhalb einer 1 Stunde sieht beim LSD die Statistik wie folgt aus 19 (19).

In der LSD Warteschlange stehen 13 Clients und warten auf UL.
3 Clients bekommen UL.

In der Wombat Warteschlange stehen sage und schreibe nur 2 Clients.

eWombat : Hide Overshare = aus

Wofür der eWombat eine Woche gebraucht hat, macht der LSD in 1 Stunde.

Wieso gibt es einen so gravierenden Unterschied ?

[Xman]

blomy,
um das ganze nun objektiv zu bewerten (ob der ewombat was schlechter macht oder der LSD etwas besser) würd mich interessieren wie es mit nem dritten Mod aussieht.

[Blomy]

@ Xman, es geht mir nicht ums bewerten.
Vielleicht habe ich mich auch nur verkehrt ausgedrückt.
Ich habe meinen Text nochmal überlesen und der Eindruck könnte entstehen.
Ist aber nicht in meinem Sinn.

Ich möchte wissen, wieso das so ist.

[Anonymous]

blomy, was ist, wenn du jetzt vom lsd wieder zurück zum wombat gehst. wird es dann wieder so gravierend schlechter?

[Blomy]

Ich habe ja die 2 Files schon eine Woche im DL gehabt. Und irgendwie ging
es dabei nicht vorwärts. Wenn ich jemanden gebe, bekomme ich ja auch
schneller zurück. Dabei wollte ich diese beiden Files ein wenig pushen.
Aber wenn kaum jemand in der Warteschlange steht, kann man ihn ja nicht
pushen. Der Wombat soll weiter drauf bleiben. Da geht kein Weg dran vorbei.
Ich sage nur SNAFU.
Und dann bin ich auf die Idee gekommen, es mit einem anderen Mod mal
auszuprobieren. (Ich hatte gerade den LSD gezogen und der musste halt eben
zu Testzwecken dran glauben).
Ausserdem habe ich den DL im Wombat abgebrochen, es kamen ja kaum Clienten.
Jetzt muss der LSD parallel zum Wombat eben diese 2 Files zu Ende saugen.
Ausserdem warten jetzt schon 16 Clients auf UL. Soviele habe ich beim
Wombat noch nie gehabt. Das höchste, was ich gesehen habe, waren 7.

Wo ich die Files noch im Wombat hatte, waren 4 Clients in der QR vorhanden
und dann auf einmal nur noch einer und der verschwand dann auch noch.
Und laut der Balkenstatistik benötigen sie Parts von mir. Eindeutig.
Das mal einer verschwindet, weil er keinen Part mehr braucht oder die
Verbindung nicht zu stande kommt oder oder .
Aber 1 Woche lang immer dasselbe Phenomen ?

Und genau das hat mich neugierig gemacht.

[Xman]

blomy,
Ich kenne dieses Phenomen nur zu gut. Sowas fällt einem halt nur bei files auf mit wenig Quellen. Wie gesagt ich kenne das, lud ich mal an nem File ca. 3 Monate, da auch hier imemr die Quellen verschwanden.

Mein Vorheriges Statement sollte nicht auf eine Bewertung der Mods rauslaufen. Dennoch muß es doch nen unterschied geben. Und der ist nun mal, daß entweder der ewombat irgendetwas schlechter macht als normal, oder der LSD irgendetwas besser. Sollte der LSD ein Geheimrezept haben wäre es doch sehr sinnvoll dies rauszufinden damit vielleicht auch darkwolf davon profitieren kann.

[Blomy]

Erweiterung der Statistik :

Seit 15:30 Läuft der LSD10c parallel zum Wombat 0.063.
Seit dieser Zeit stehen 3 Clients im UL und 13 in der Warteschlange beim LSD. Immer.
Und ich bekomme auch DL von diesen Clients.

[darkwolf]

Hi,

Ich werde mir mal den Source vom LSD10c zu gemüte führen und schauen, was der genau macht...

cu
darkwolf

[DQA321]

darkwolf,

mach das mal

[darkwolf]

Hi,

der LSD-Mod benutzt eine TCPIP connection timeout von 60 sekunden d.h. bei ihm bestehen höhere chancen zu einen langsamen source zu connecten (z.b. modem)

Diesen wert kann man beim eWombat bei den eWombat TCPIP-Einstellungen verändern. Das hat aber wieder Auswirkungen auf die aktiven Verbindungen und den 'zu viele Verbindungen'

cu
darkwolf

[Xman]

darkwolf,
ich hab genau dazu mal ne Frage.. und zwar ist meine Ansicht richtig ?

Eine TCP-Connection zur Abfrage einer Quelle verbraucht nur beim Eröffnen Bandbreite und dann wenn der Befragte antwortet.
Eine TCP-Connection wird aber während des ganzen Bestehen etwas CPU und Speicher verwenden (so wenig, daß dies zu vernachlässigen ist).

Wenn diese 2 Punkte korrekt sind, dann würden die "mehr"-Connections durch Erhöhung des TCP timeouts nicht mehr Bandbreite verbrauchen.

Da moderne Betriebssysteme (also ab w2k) keine Probleme haben viel hundert Connections gleichzeitig zu verwalten wäre es sinnvoll, das TCP timeout gleichzeitig mit der Anzahl der gleichzeitig möglichen Maximalverbindungsanzahl zu erhöhen ohne Performanceeinbußen zu haben.

Lieg ich richtig ?

[Blomy]

@ darkwolf
Ich habe diese Einstellungen zwar gesehen, aber nichts geändert.
Werde ich mit anderen Werte ausprobieren.

Vielen Dank für die Auskunft.

[Usul]

Ich hab mal zu Testzwecken die Timeouts von 40 auf 80 Sekunden erhöht, ich merke keinen Unterschied, weder im positiven noch im negativen Sinne.

[darkwolf]

Hi,

@Xman, mit deinen Anahmen hast du recht, das Problem ist der eMule selber, wenn du hohe timeout werte hast bleiben die connections länger offen und die Anzahl der Verbindungen steigt, was wieder zu mehr 'zu viele Verbindungen führt'. Und die höheren Timeout werte helfen auch bloss bei Verbindungen zu langsamen Clients (mit z.b. Modem oder in Asien). Und die Frage ist auch, ob deine Netzwerk (DSL-Modem, Router usw.) so viele Verbindungen verkraftet.

@Usul, ist bei mir genause ein connection-timeout von 60 hat überhaupt nichts gebracht, eins von 20 hat die Quellen wesentlich schneller abgefragt, dafür aber einige (12 von 800) ignoriert (status unbekannt). Beim Upload hat sich nie etwas verändert.

cu
darkwolf

[Xman]

darkwolf,
mehr "zu viele Verbindungen" dürfte aber nicht sein, wenn man wie erwähnt das Verbindungslimit mit raufsetzt. Schließlich wird weiterhin die gleiche Menge an Clients abgefragt.
Wie findet man eigentlich am besten raus, wieviele Verbindungen das Netzwerk verkraftet ?
Ok, ich kenn den Test von speedmeter.de, doch bin ich mir nicht sicher wie Aussagekräftig dieser ist.