eMule einstellen - habe ich es richtig verstanden?

[Tranio]

(Vorab: Die entscheidenden Größen kann man ablesen unter Statistik/ Transfer/Download/Session/Gefundene Quellen)

(ich benutze "normales" DSL, bei neueren Technologien gelten entsprechend höhere Zahlen)

1) Es gibt Quellen. Bei jeder Quelle stellt sich der Client in der Warteliste an. Bei vollen Wartelisten oder wenn es keine benötigten Teile gibt, versucht es der Client zu einem späteren Zeitpunkt nochmal.

2) Zu jeder Wartelisten-Quelle baut der Client alle 20 Minuten eine Verbindung auf, um die Wartelisten-Position zu überprüfen und ggf. den Download zu starten.

3) Die beiden genannten Tätigkeiten verbrauchen die knappste Ressource, die sogenannten "Verbindungen".

4) Sind die Verbindungsreserven überstrapaziert, verursacht das hohe Kosten, d.h. der Download wird gehemmt:
- Ein hoher Overhead hemmt den Upstream und verhindert so den Erwerb von Credits
- Gelingt die Aktualisierung einer Wartelistenquelle nicht, muss sich der Client wieder hinten anstellen

5) Optimal eingestellt ist der Client, wenn er sich bei einer möglichst großen Zahl von Quellen angestellt hat, diese Anstellungen auch alle 20 Minuten bedienen kann und gleichzeitig mit einem Maximum von 80% der upstream-Kapazität auskommt.

Das heißt beim Einstellen von eMule:

I) upload zwischen 10-12 einstellen, download beliebig groß (wird eh fast nie ausgeschöpft werden).

II) Bei "max. Verbindungen", "max. neue Verbindungen pro 5 sek." beliebig hohe Werte einstellen, z.B. 500 und 80. Diese Größen eignen sich nicht zum regulieren des Systems.

III) Eine vernünftige Menge an Quellen ansteuern. Sinnvoll ist es, in der ersten Stunde des Programmlaufs die Quellenzahl von ganz unten an zu erhöhen, indem bei "Hardlimit" ein immer höherer Wert eingestellt wird. Erfolgreich ist man, wenn man eine steigende Zahl bei "In Warteschleife" sieht und bei "zu viele Verbindungen" einen Wert konstant unter 50. Indem man die Quellenzahl nur langsam ansteigen lässt, verhindert man "zu viele Verbindungen." Ab einer bestimmten Grenze lässt sich die Quellenzahl nicht mehr erhöhen, ohne dass durch "zu viele Verbindungen" unerwünschte Friktionen eintreten.

Bei "normalem" DSL habe ich atm mit 2300 Quellen als "Zielwert" gute Erfolge (25-35kB/s)



Ich würde gerne wissen, ob diese "Beobachtungen" auch technisch korrekt sind. Wenn ja, hätte ich einige Ideen, wie man das System effizienter machen kann bzw. die Clients verbessern.

[Pathfinder]

Willkommen an Board, Tranio!

Schön, dass du dir um die Problematik der Verbindungen und des Overheads Gedanken machst, zu viele User schenken dem keine Beachtung, überfordern System und Client und schädigen damit die Community.

Vorab: Unsere Empfehlungen bzgl. der eMule-Einstellungen kannst du der Xman-FAQ entnehmen.

2) Zu jeder Wartelisten-Quelle baut der Client alle 20 Minuten eine Verbindung auf, um die Wartelisten-Position zu überprüfen und ggf. den Download zu starten.

Bei den aktuellen Kademlia-Clients sind es 29 min.

3) Die beiden genannten Tätigkeiten verbrauchen die knappste Ressource, die sogenannten "Verbindungen".

Jede Anfrage an einen Client egal welcher Art benötigt eine Verbindung. Die Daten die bei einer solchen Verbindung gesendet / empfangen werden sind als Overhead anzurechnen.

4) Sind die Verbindungsreserven überstrapaziert, verursacht das hohe Kosten, d.h. der Download wird gehemmt:
- Ein hoher Overhead hemmt den Upstream und verhindert so den Erwerb von Credits
- Gelingt die Aktualisierung einer Wartelistenquelle nicht, muss sich der Client wieder hinten anstellen

Hier fängst du an zu "schwimmen", der Download wird indirekt gehemmt. Da der Upload bei "normalem" DSL den Engpass darstellt, beeinträchtigt hoher Overhead, verursacht durch zuviele Verbindungen, zunächst diesen. Sinkt der Upload von Nutzdaten auf Kosten des Overheads werden weniger Credits erwirtschaftet. Dies hat indirekt Auswirkungen auf den Download durch längere Wartezeiten, Ratiobeschränkungen.

Ein Client der sich nicht pünktlich gemeldet hat um seine Wartelistenposition zu checken verliert nicht sofort all seine Wartezeit (siehe auch SUQWT).

Die "Verbindungsreserven", wie du es nennst, sind ein weiterer Knackpunkt, die Menge an Verbindungen die ein System verwalten kann ist abhängig von Hardware und Internetanbindung. Daher irrst du bei folgender Aussage:

II) Bei "max. Verbindungen", "max. neue Verbindungen pro 5 sek." beliebig hohe Werte einstellen, z.B. 500 und 80. Diese Größen eignen sich nicht zum regulieren des Systems.

Ausgehend davon, dass jedes System nur eine bestimmte Zahl an Verbindungen pro Zeiteinheit verwalten kann haben die Größen max. Verbindungen und max. neue Verbindungen pro 5 sek. sehr wohl eine große Bedeutung.
Hier sei insbesondere die Einschränkung durch schwache Router genannt, im SubForum "DSL Router" kannst du nachlesen welche Probleme auftreten wenn diese beiden Werte nicht sorgfältig gewählt und optimiert werden.

Aber auch der Overhead lässt sich darüber steuern, fragst du viele Quellen nämlich langsamer ab (-> kleiner Wert bei max. neue Verbindungen pro 5 sek.), werden weniger gleichzeitige Verbindungen aufgebaut, und der Overhead bleibt kontrollierbar. Gleiches gilt für ein Verbindungsmaximum, hierbei beschränkst du indirekt auch den Overhead auf ein Maximum. Beide Werte solltest du bei deiner Optimierung also mit einbeziehen.

[Tranio]

Danke auf die verlinkten FAQs, die ich mir natürlich auf meiner Reise durch p2p-Boards angesehen habe. Was das SUQWT-Feature genau bringt, ist mir nicht klar, auch wenn ich mir eine Anwendung vorstellen könnte (dazu später mehr).

Ausgehend davon, dass jedes System nur eine bestimmte Zahl an Verbindungen pro Zeiteinheit verwalten kann haben die Größen max. Verbindungen und max. neue Verbindungen pro 5 sek. sehr wohl eine große Bedeutung.

Du sagst es selber, die Grenze liegt im System. Ich kann durch Einstellung niedrigerer Werte höchstens für andere Anwendungen die Verbindungsressourcen freihalten. Die Konsequenzen von falschen Einstellungen hier, außer es sind routerspezifische Probleme, würden mich schon interessieren. Ich meine aber, dass es sinnvoller ist, diese Größe durch Quellenmanagement zu regulieren.

Aber auch der Overhead lässt sich darüber steuern, fragst du viele Quellen nämlich langsamer ab (-> kleiner Wert bei max. neue Verbindungen pro 5 sek.), werden weniger gleichzeitige Verbindungen aufgebaut, und der Overhead bleibt kontrollierbar. Gleiches gilt für ein Verbindungsmaximum, hierbei beschränkst du indirekt auch den Overhead auf ein Maximum. Beide Werte solltest du bei deiner Optimierung also mit einbeziehen.

Der Nutzen eines geringeren Overheads für den User ist aber ausschließlich der höhere eigene Upstream. Das ist zuwenig. Der "downloadwerte Vorteil" (Nutzen) von Uploaden ist in diesem Bereich deutlich geringer als der "downloadwerte Vorteil" (Nutzen) davon, sich munter bei mehr Leuten anzustellen, bei anderen mehr Overhead zu erzeugen und dem System weniger zu geben.

In der Ökonomie werden solche Probleme spieltheoretisch analysiert. Jeder Agent hat zwei Handlungsoptionen betreffs der Verwendung des betroffenen Upstreams (ich schätze 2kB/s bei "normalem" DSL): Er kann diesen entweder zum uploaden verwenden oder aber sich in mehr Warteschlangen anstellen. Alle Agenten im Netzwerk haben diese Wahl, und für jeden einzelnen ist die zweite, unkooperative Variante die bessere, unabhängig davon, was die anderen Netzwerkteilnehmer machen. Somit werden alle eher weniger uploaden und eher die Kosten des Overheads risikieren, um sich für mehr Downloads anstellen.

Eine Lösung dieses Problems könnte darin bestehen, den "Wert" eines Credits zu erhöhen, ihn etwa zu verzehnfachen. Außerdem erhielte jeder User ein geringes "Startguthaben". Letztlich würde sich der Download des einzelnen langfristig auf dem Wert DL = UL * (1+x) einpendeln, wobei x ein möglichst zu minimierender, aber positiver (außer jemand WILL nicht downloaden) Restwert ist; x repräsentiert insbesondere die Chance, auch ohne Credits "zum Zug" zu kommen

Dadurch würden gleich drei Ziele erreicht:
1) DL würde gerechter verteilt
2) Ein Beitritt zum Netzwerk ist weiterhin möglich, auch ohne gefragten Share ("x", sowie Startguthaben)
3) Overhead würde vermieden, da "Anstellen" wenig Sinn macht, wenn man die Queue oft eher runter- als raufkommt

Das Startguthaben müsste so gering ausfallen, dass die Installationszeit ähnlich viel entgangenen Upload verursacht, d.h. installieren lohnt sich nicht. Dazu müsste es "erschwert" werden, die Client-ID zu ändern, etwa indem bei Modifikation der Client-ID alle Konfigurationen resettet werden. Auch ohne eine solche "Erschwerung" würden Trittbrettfahrer vermutlich durch ID-Wechsel weniger Overhead verursachen, als wenn sie sich bei tausenden von Quellen anstellen.

Einziges Problem dabei: Wir Europäer in der "Welt-ADSL-Zone" könnten nicht mehr über "DL=UL" hinaus leben, solange unser Upstream faktisch auf 13kB/s limitiert ist. Immerhin könnte man so viel Overhead sparen.



Nun zum zweiten Thema: SUQWT oder: warum alle 20 Minuten eine Verbindung machen? Clients sollten so umgestaltet werden, dass beim "Anstellen" eine Prognose gesendet wird, nach wie viel Minuten man "dran" sein könnte. Ich bin mir aber nicht sicher, inwiefern dadurch in relevantem Maße Upstream für UL freigemacht werden kann.

Danke fürs Lesen, das waren zwei "ökonomische" Überlegungen zu dem Thema.


[edit by Pathfinder: Doppelposts zusammengefasst. Board-Rules beachten!]


huch!

ich muss mich korrigieren! vermutlich funktionieren Credits ein wenig anders, als ich mir das vorgestellt hatte. Ist es vielleicht so, dass Credits wie bei einer Auktion "aufgewandt" werden müssen, um in der Warteliste an einen besseren Slot zu kommen, und der mit den meisten Credits kriegt den besten Slot, verliert aber auch entsprechend Credits, der mit den zweitmeisten bekommt den zweiten usf.

Wenn dem so wäre, müsste eine Veränderung des Credit-Systems eher so aussehen: 2 kB/s für UL auch ohne Credits, Rest des UL nur für Leute mit Credits, es sei denn, es gibt keine, dann Freigabe.

Oder so?

[Pathfinder]

Zitat von Tranio

Was das SUQWT-Feature genau bringt, ist mir nicht klar, auch wenn ich mir eine Anwendung vorstellen könnte (dazu später mehr).

SUQWT = Save UploadQueue Waiting Time
Dieses Feature speichert die Wartezeit von Clients, damit sie, falls sie es nicht schaffen sich in einem Zeitlimit wieder zu melden, wieder in die Warteschlange eintreten können ohne zuviele Plätze zu verlieren.

Zitat von Tranio

ich muss mich korrigieren! vermutlich funktionieren Credits ein wenig anders, als ich mir das vorgestellt hatte. Ist es vielleicht so, dass Credits wie bei einer Auktion "aufgewandt" werden müssen, um in der Warteliste an einen besseren Slot zu kommen, und der mit den meisten Credits kriegt den besten Slot, verliert aber auch entsprechend Credits, der mit den zweitmeisten bekommt den zweiten usf.

Was die Credits betrifft besteht wohl noch ein wenig Erklärungsbedarf.
Die Credits basieren auf der übertragenen Datenmenge und funktionieren ähnlich wie Schulden, d.h. sie werden durch Datentransfer in die Gegenrichtung "getilgt".
Für die Berechnung der Position in der Warteschlange spielen sie ebenfalls als Faktor eine Rolle, werden dabei aber nicht "aufgebraucht".