Wie wird die übertragene Rate eigentlich ermittelt??
 

Wird beim Emule eigentlich die Bitrate angezeigt und in die Credits aufgenommen, die Physikalisch versendet wird, oder die, die existiert, bevor die Daten komprimiert wurden? :?:

Hallo WillWasLernen,

ich bin ein wenig unsicher. Zum einen, weil ich nicht ganz sicher bin, ob ich Deine Frage richtig verstehe.
Du möchtest wissen, ob Du für unkomprimierte 9,3 mb Daten auch Kredite für diese Datenmenge bekommst, auch wenn durch Kompression daraus, sagen wir einmal, 8,5 mb geworden sind?

Ich vermute: Ja. Aber das ist nur eine Vermutung. Mir fehlt das Wissen, um diese Frage abschließend zu beantworten (der zweite Grund meiner Unsicherheit). Aber an wirklichen Experten leidet dieses Board keinen Mangel und darum denke ich, daß wir beide in ein paar Stunden wieder etwas haben lernen können.

Mit freundlichen Grüßen
aalerich

P.S.: Die Frage gefällt mir (vorausgesetzt, ich habe sie richtig verstanden). Bin auch auf eine Antwort gespannt.

Hi WillWasLernen,

lt. http://www.emule-project.net/home/pe...c&topic_id=317
wird die ÜBERTRAGENE Datenmenge zur Creditberechnung benutzt. Also egal ob komprimiert oder nicht, die Mehrmenge durch Komprimierung wird nicht beachtet.

Angezeigt im Muli wird meines Wissens auch die Übertragungsgeschwindigkeit (also ohne Komprimierungsmehrwert). Allerdings ist die Messung nicht immer genau, gerade wenn der Muli richtig unter Last ackert, sind diese angezeigten Geschwindigkeiten bei mir ab und zu mal deutlich überhöht.

Mir gehts bei dem nächsten Antwortteil aber ähnlich wie Aalerich, genau wissen tue ich es nicht, aber ich glaube ich habe da auch mal was drüber gelesen.
Blöderweise spielt es nämlich auch keine Rolle, ob die übertragenen Daten wirklich in Ordnung sind. Selbst für defekt übertragene Daten (wenn der Muli per Hashberechnung als defekt erkannte Chunks wegschmeißt) gewährt der Muli dem Absender Credits. Zumindest war das in früheren Muliversionen so, vielleicht auch jetzt noch?

Würde mich auch interessieren, wenn da jemand genaueres zu weiß.

Ciao
Rumpelzuck

Hallo WillWasLernen, hallo Rumpelzuck,

Schon das halte ich eher für unwahrscheinlich. Dateien werden, so denke ich, in unkomprimiertem Zustand gehasht. Ein Chunk wäre also unkomprimiert 9,3 mb groß, nicht komprimiert. Und wenn der übertragen wurde, wird dem Sender diese Menge gutgeschrieben. Alles andere halte ich für viel zu aufwendig. Das würde heißen, daß die Kompression nicht zum Versand einer größeren Datenmenge ("Mehrmenge"), sondern nur zur Zeitersparnis und Ressourcenschonung führt. Die Nutzung der Datenmenge im komprimierten Zustand würde z.B. voraussetzen, daß alle Teilnehmer am Netzwerk komprimieren (können), und zwar alle gleich. Ich weiß nicht, ob die Kompression von Anfang an eingesetzt wurde. Aber selbst wenn, würden die komprimierten Größen genutzt, würde dadurch wahrscheinlich die Kompressionsmethode auf alle Zeiten festgelegt sein. Ein Umstieg auf eine neue, bessere Methode wäre nicht (oder eben nur auf einen Schlag bei absolut allen Teilnehmern) möglich. Anderenfalls wären die Chunks je nach der vom jeweiligen Muli verwendeten Kompressionsmethode unkomprimiert unterschiedlich groß.

Meine Beobachtung: Das System ist ausgelastet, das Muli überträgt weiter Daten, die ja aber nicht wirklich wichtige Echtzeitberechnung der Übertragungsgeschwindigkeit wird quasi "ausgesetzt". Sind wieder Systemressourcen frei weiß das Muli zwar, wieviele Daten es verschickt hat. Es weiß aber nicht mehr, wie lange es dafür gebraucht hat. Deshalb macht es sich die Sache einfach und addiert die während des "Aussetzers" übertragenen Daten einfach zu denen, die im ersten Zeitabschnitt nach dem Wiederfreiwerden der Systemressourcen gesendet wurden. Und dann zeigt es halt für jeden einzelnen Uploadslot ganz kurz Übertragungsraten an, die ein Vielfaches der gesamten Leitungskapazität betragen.

Nun ja, ich denke, das geht auch nicht anders. Die Einstufung eines Parts als "ok" oder "corrupted" ist zwangsläufig problematisch (Stichwort "I.C.H" oder "defeat 0-filled parts sender" an- bzw. abschalten). Die endgültige Beurteilung kann nur ein Mensch vornehmen. Deshalb ist es nicht schön, aber eben nicht anders zu machen, als auch solchen bewußten oder unbewußten "Saboteuren" Credits zu geben.

Mit freundlichen Grüßen
aalerich

Soweit stimme ich dir zu. Ausser in den Sonderfällen von kleinen Dateien bzw. Reststücken am Ende großer Dateien. Die Chunkgröße bezieht sich immer auf die originalen Daten.

Das ist meiner Meinung nach anders. Es wird nur die tatsächlich übertragene (und evt. dabei komprimierte) Datenmenge als Credits gutgeschrieben. Das führt in der Tat dazu, daß ein Client der einen Chunk gut komprimiert überträgt, weniger Credits dafür erntet, als für einen unkomprimiert übertragenen Chunk.

Weitere Meinungen zu dem Thema und Hinweise auf Quellen für weitere Erklärungen sind willkommen. :-)

Alles andere wäre ungerecht. :wink:
Gezählt wird nur das Übertragene und nicht das, was Sender und Empfänger per Kompression hinein oder eben auch nicht hinein gesteckt haben. Die Kompression wurde genau aus den oben von dir genannten Gründen eingeführt.
Wenn z.B. ein 9,3 MB großer Chunk auf 5MB komprimiert übertragen wird, werden eben tatsächlich in einer Übertragung nur 5 MB physikalisch über die Leitung geschickt und auch nur diese Menge vom Empfänger dem Sender als Credit gutgeschrieben.

Bei dieser Art der Berechnung treten eigentlich auch keine Kompatibiltätsprobleme auf, entweder beide Partner unterstützen die gleiche Komprimierungsmethode, dann gehts per Kompression, oder wenn nicht dann eben Übertragung ohne Kompression.

Könnte man mal mit ein paar gut zu komprimierenden Daten testen, vielleicht Textdateien?

Die Einstufung von Chunks in rechnerisch "ok" oder "corrupt" kann der Muli aber gerade sehr gut machen, dafür sind ja gerade die Hash Werte gedacht. Theoretisch könnte schon zuverlässig für defekte Chunks die Creditgewährung aufgehoben werden. Es wäre halt nur oft auch ungerecht gegenüber dem Sender, weil es ja nicht zwangläufig seine Schuld sein muss.
Aber inzwischen gibts ja einige "Quellen", die vorsätzlich und nur defekte Sachen senden. Das Abblocken dieser vorsätzlichen Störer im aktuellen 44d Muli ist da sicher die bessere Methode.

"defeat 0-filled parts sender" ist ein zweischneidiges Schwert. Wenns aktiviert ist ist, kann man defekte Chunks damit genauso gut empfangen wie ohne, nur eben keine fast nur mit Nullen gefüllten.
Diese "leeren" und sehr gut zu komprimierenden Chunks können aber bei einigen Dateiarten (z.B. CD/DVD Images) durchaus vorkommen und dann verhindert diese Funktion den Empfang. Ich lasse es immer aus.

Ciao
Rumpelzuck

Hallo Rumpelzuck,

Soll ich mal ehrlich sein? Auf die Variante bin ich gar nicht gekommen. Naja, den Wald wieder vor lauter Bäumen nicht gesehen... :-)

Und mit den Krediten mußt Du eigentlich auch recht haben. Alles andere wäre ja ein traumhafter Ansatz für Leecher; einfach nur die Chunks einer Datei hochladen, die sich am besten komprimieren lassen...

Ich habe eben eine .doc-Datei von 260 kb gezogen und die Detailansicht des Lieferanten bescheinigte diesem, 32 kb geschickt zu haben. Es ist also wohl wirklich so, wie Du sagst. Nebenbei: Welche Kompression ist das eigentlich? Als .zip kriege ich die Datei nur auf 34 kb zusammengedrückt, als .rar allerdings auf 24 kb..

Mit freundlichen Grüßen
aalerich

Hi aalerich,

vielen Dank für deinen Test. :)
Die Kompressionsmethode für Datentransfer kenne ich auch nicht, aber vielleicht so ein Opensource Packer wie GZIP, der auch für die Kompression der Muli-Webserverdaten benutzt wird.

Ciao
Rumpelzuck

um den Spekulationen Wahrheit zu verleihen: Rumpelzuck hat natürlich recht. Schließlich isser ja auch QualityOfService :)

Tatsächlich übertragene Datenmenge (also Anzahl der Bits und Bytes die über die Leitung gehen) wird in die Credits reingerechnet. Wenn also ein Client einen Fakechunk sendet, d.h. 33kb tatsächlich sendet, aber 9,28 (Chunkgröße! nicht 9,32) fertiggestellt werden können, bekommt der Client nur Gutschrift für 33 kb. (=keine Credits, da Credits erst ab 1.000.000 Bytes zum tragen kommen)