Achillesferse Upload

[MxM]

das problem ist nicht die bandbreite... der client hatte sich einen queue platz erarbeitet...genauso wie der andere... nun ist der abgearbeitet, und er muss für seinen, denselben chunk wieder anstehen...

das ein ausgleich über 2 sekunden entstanden ist, bis der "kräftigere" mod dazugekommen ist... finde ich nicht ganz fair... dieser wäre nach dem chunk sowieso dran gekommen...


ich weiß was du sagen willst... aber stell dir vor ... 2 uploads alufen ... nach 10 MB wird nummer 2 getrennt... nummer 1 ist bei 9 MB ... jetzt kommt ein neuer client... und statt wie in deinem fall dass der neue abfällt, bekommt der neue beim hochschnellen den vollen transfer und der erste chunk fällt ab... (schon beobachtet)... dann gehen 9 MB verloren

ist erstmal nur ein beispiel... aber das prinzipielle problem hast du sehr wohl beobachtet, wenn auch von der etwas positiveren seite...

aber gut, solche beobachtungen finde ich klasse. so kommen wir der sache auf den grund

[Usul]

Wenn ich mich aber auf den Standpunkt stelle, das der Client, der bei mir drankommen sollte, ein Problem hatte und der Transfer deshalb nicht zustande kam (weswegen auch immer), dann hat mein Emule doch das beste aus der Situation gemacht. Er hat versucht, dem nächsten in der Queue zu geben, was ihm zusteht, hat aber dabei keine Bandbreite sinnlos reserviert, sondern sie jemand anderem zur Verfügung gestellt, und als der nächste nicht geantwortet hat (warum auch immer), kam der übernächste dran. Für mich das optimale vorgehen (in diesem speziellen Fall).

[MxM]

dann würde es aber ausreichen, wenn beim client dastünde download fehlgeschlagen... der upload ist ja dann nicht von dir unterbrochen worden...


also müßte man quasi unterscheiden, in selbstverursachte, und fremdverursachte .... allerdings fallen lange leitungswege, wie bei renegade ...weder unter das eine noch das andere...

also wenn zwischen 2 relaisstationen das signal verloren ging... hat weder dein noch der andere mule schuld

wenn ich mir aber vorstelle, der 2te slot hätte die geschwindigkeit beibehalten und der 2te client hätte eine höhere bandbreite bei dir zur verfügung gehabt, ohne sich hochkämpfen zu müssen, so denke ich mir sehr wohl, dass der ping zwischen euch kürzer gewesen wäre, und somit ein langer leitungsweg nicht zu einem fehlschlag geführt hätte..


also die probleme sind vielfältig...deswegen hatte ich damals bei badwolf auch doppelte timeoutzeit angeregt... und offensichtlich auch nach mehrwöchigen erfahrungen, hat genau das zu einer sehr großen leistungssteigerung geführt und zu weniger ausfällen ... und das sogar, ohne bandbreite zu verlieren, wie das aus deinem beispiel als umkehrschluss hervorgehen könnte.


aber wichtig finde ich es, wenn wir solche situationen zusammentragen können.... ich glaube betatester haben kaum solche möglichkeiten das so zu testen... viele fehler sind unentdeckt, weil ihre ursachen nur schwer sichtbar sind

[Anonymous]

Zitat von Usul

Ich habe live gesehen, wie ein fehlgeschlagener Upload hinzukam. Dabei ist aber keine Uploadkapazität verloren gegangen, sondern die freie Kapazität bei einer nicht zustande gekommenen Übertragung wurde für eine andere benutzt. Der fehlgeschlagene Upload in der Statistik hatte also keine Uploadbandbreite vergeudet. Das muß vielleicht nicht bei jedem fehlgeschlagenen Upload so sein, bei einige aber ganz bestimmt, was die hier geführte Analyse von Failed:Success (oder umgekehrt) etwas relativiert.

hab das auch schon öfters bepbachtet ..... und in der ganzen zeit, in der emule versucht zu verbinden und es klappt nicht, überträgst ja auch nichts. sicher, der andere slot geht dafür zum ausgleich etwas hoch, aber es wird nicht die gesamte bandbreite dafür genutzt. sogesehen wird schon ein teil deiner bandbreite für kurze zeit nicht genutzt. ist zwar nicht viel, und auch nur für ein paar sekunden, aber das addiert sich mit der zeit. wie heißt es doch so schön.... kleinvieh macht auch mist.
in dem sinne ....

[Usul]

Statusbericht Lovelace.9b

Laufzeit erst 4:15h (aber die Werte sind so schön )

Succes 45, Failed 5, Verhältnis 9:1

Average Uploadtime 12:59min

[MxM]

hier ist inzwischen ein router geschaltet.... mit dem router erhöht sich die ausfallrate


statt success:failed 4:1 kommt jetzt so höchstens 3:1 heraus. das mag an verschiedenen dingen liegen, aber in erster linie muss ich wieder sagen zu kurze timeouteinstellungen in den emules, denn der weg und die kontrolle ist das was am meisten dauert.... ich werde deswegen einen der neueren badwolfs testen, mal schaun, ob das timeout-timing dort mehr hilft, als die optionen die schädlicher sein könnten

[Usul]

Zitat von MxM

hier ist inzwischen ein router geschaltet.... mit dem router erhöht sich die ausfallrate

Das kann man aber auf keinen Fall pauschal sagen. Bei mir ist ein FLI4L-Router vorgeschalten, die Ergebnisse sieht man ja.

[MxM]

das ist für mich kein router, sondern ein PC mit routing software der kann vielmehr verwalten, frißt aber auch mehr strom und ist mehr lauter ) und blinkt weniger


ich muss erst noch endgültig checken woran das liegt, ich hab hitner der DMZ auf meinem rechner ne firewall (no-standard). und möglich, daß die die kommunikation mit dem router blockiert.... muss ich aber noch verifizieren

[Pan Tau]

Zitat von MxM

.... ich muss erst noch endgültig checken woran das liegt, ich hab hitner der DMZ auf meinem rechner ne firewall (no-standard). und möglich, daß die die kommunikation mit dem router blockiert.... muss ich aber noch verifizieren

Hi MxM,

sollte dein Router in der Lage sein die Ports zu mappen wäre es besser / sicherer du würdest die Ports so durchschleifen anstelle die DMZ zu nutzen, denn mit deiner entmilitarisierten Zone lädst du quasi die ganzen Script-Kiddys ein zu gucken was geht. (Alle Ports erreichbar, zwar erstmal nur bis zu deiner firewall, aber auf jeden Fall ein Angriffspunkt mehr!)

CU
Pan Tau

_________________
Be paranoid, or be hacked!

[MxM]

das problem ist, dass emule SO aggressiv ist, daß der router ALLES auf supersparflamme schaltet, weil quasi die ganze zeit storming läuft. das seh ich ja auch die ganze zeit...

ICMP storming auf port 1214, mein mule läuft auf anderen ports...



also source exchange hin und her... aber das das udp für icmp storming ausgenutzt wird hätte auch klar sein müssen... wenn ich eben über UDP die WIEDERAUFNAHME erreiche... dann erreiche ich sie wohl schneller, wenn ich storme

alle emules sollten soweiso langsames/sicheres verbinden zu servern mindestens automatisch voreingestellt haben...

und die requests sollten sich nicht auf 1 request per source per file beschränken ..sondern 1 request in 10 minuten per hash / user ...egal wieviele files ich habe


ich bin gern offen für weitere empfehlungen, aber mit port mapping läuft der upload bei unter 20% ...und der download bei unter 10%

ist ein SMC router

[MxM]

um aber kurz aufs thema auf andere weise zurückzukommen, möchte ich kurz erwähnen dass ich durch folgende dinge die failed statistic zurückschrauben konnte



von 200 max. connection 200 sources per file auf je 150 ging die failed shcon leicht zurück

und dann habe ich aus meinem share dateien verschoben (auch temp ordner).

kontrolliert 5 dateien im temp und nicht mehr als 5 GB im share hat zu einer weiteren verbesserung geführt.

[MxM]

und ich hab nochwas interessantes gefunden bei der neuen Version von enkeyDEV.

l2hac lowid to highid automatic callback:

A simple idea to avoid useless server load: when a lowid user enqueues a highid, it's useless the latter asks the (common) server for a callback request every 21'40".
This mod makes the lowid connect to the highid automatically every time without waiting for the server callback.
It works as well with most of not-modded-emule-clients: every time the not-modded highid try the connection, it finds itself already connected and make the request immediately without server callbacks.

This gives:
- less server load (the AVERAGE server callbacks avoided are between 4 to
- better lowid UL (if the lowid changes server, the highid is kept on queue and constantly updated)

Does it work? Some statistics (over about 100000 tries):
- L2HAC connection successful: 92%
- Reask received: 85%
Most of failure is due to clients with a non-standard reasktime value (21'40")



Most of failure is due to clients with a non-standard reasktime value (21'40")

[Pan Tau]

Zitat von MxM

dafür läuft der emule plus 1c bei mir ganz toll ...

.... ULL ist übrigens ganz offensichtlich auf 1:1 festgeschraubt was ich SEHR richtig finde ! Save the network!

Bist du dir sicher das er festverdrahtet ist? Ich hab das zwar bisher noch nicht extra beobachtet glaube aber dass ich immer noch mehr bekomme als rausgeht wenn ich mal mein Maultier kontrolliert habe. Ich muss dazu sagen dass ich die "eMule.tmpl" und die "eMule.exe" einfach in's bestehende Programmverzeichnis kopiert habe und von daher auch die ganzen (statistischen) Werte von den vorherigen Versionen "mitschleppe".

Pan Tau

[Pan Tau]

noch ein paar werte: eMule plus v1c (Limits auf 90k, 11k) auf XP-Pro (SP1); AMD XP1800+; 256MB DDR333; ENMIC 8TTX3+; 128MB GF4 TI-4200; T-DSL 768/128; im Netzwerk über Hardwarerouter CO-SA (NoNameProduct)

online seit 4T 3H
erfolgreiche Uploads: 1350
fehlgeschlagene Uploads:270
durchschnittliche Uploaddauer: 18:35min
Verhältnis erfolgreich / fehlgeschlagen: 5:1

Das heisst dann bei mir löppt die v1b besser im Upload und ich werd sie wohl auch wieder in Betrieb setzen auch wegen der vielen kleinen unsauberkeiten im code von v1c.
Ach, und zum Thema Abstürze die plus v1b und v1c sind bei mir noch nie abgeschmiert, trotz intensiver Nutzung abseits von eMule (Spiele, surfen, Textverarbeitung, brennen).

Pan Tau

[MxM]

mit router dazwischen geht mein failed über den success


ich hab nix verändert, ich weiss nicht was ich machen soll