[eMule-Web]  

Zurück   [eMule-Web] > eMule > eMule Allgemein

eMule Allgemein Alles zur originalen Version von eMule - Bitte FAQ beachten.

Antwort
 
LinkBack Themen-Optionen
Alt 27. November 2004, 23:39   #1
Newbie
 
Registriert seit: 27.11.2004
Beiträge: 2
Standard: Wie wird die übertragene Rate eigentlich ermittelt?? Problem: 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?
WillWasLernen ist offline   Mit Zitat antworten
Alt 28. November 2004, 00:31   #2
Board Methusalem
 
Benutzerbild von aalerich
 
Registriert seit: 31.05.2004
Beiträge: 2.800

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.

aalerich ist offline   Mit Zitat antworten
Alt 28. November 2004, 12:47   #3
Senior Member
 
Registriert seit: 06.10.2003
Beiträge: 300
Standard: Wie wird die übertragene Rate eigentlich ermittelt?? Wie wird die übertragene Rate eigentlich ermittelt?? Details

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

Rumpelzuck ist offline   Mit Zitat antworten
Alt 28. November 2004, 15:07   #4
Board Methusalem
 
Benutzerbild von aalerich
 
Registriert seit: 31.05.2004
Beiträge: 2.800
Standard: Wie wird die übertragene Rate eigentlich ermittelt?? Lösung: Wie wird die übertragene Rate eigentlich ermittelt??

Hallo WillWasLernen, hallo Rumpelzuck,

Zitat:
Zitat von Rumpelzuck
...die Mehrmenge durch Komprimierung...
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ß.

Zitat:
Zitat von Rumpelzuck
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.
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.

Zitat:
Zitat von Rumpelzuck
Blöderweise spielt es nämlich auch keine Rolle, ob die übertragenen Daten wirklich in Ordnung sind.
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
aalerich ist offline   Mit Zitat antworten
Alt 28. November 2004, 16:48   #5
Senior Member
 
Registriert seit: 06.10.2003
Beiträge: 300
Standard: Wie wird die übertragene Rate eigentlich ermittelt?? Wie wird die übertragene Rate eigentlich ermittelt?? [gelöst]

Zitat:
Zitat von aalerich
Dateien werden, so denke ich, in unkomprimiertem Zustand gehasht. Ein Chunk wäre also unkomprimiert 9,3 mb groß, nicht komprimiert.
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.

Zitat:
Zitat von aalerich
Und wenn der übertragen wurde, wird dem Sender diese Menge gutgeschrieben.
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.

Zitat:
Zitat von aalerich
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.
Alles andere wäre ungerecht.
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?

Zitat:
Zitat von aalerich
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.
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
Rumpelzuck ist offline   Mit Zitat antworten
Alt 29. November 2004, 00:38   #6
Board Methusalem
 
Benutzerbild von aalerich
 
Registriert seit: 31.05.2004
Beiträge: 2.800

Hallo Rumpelzuck,

Zitat:
Zitat von Rumpelzuck
...entweder beide Partner unterstützen die gleiche Komprimierungsmethode, dann gehts per Kompression, oder wenn nicht dann eben Übertragung ohne Kompression.
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
aalerich ist offline   Mit Zitat antworten
Alt 29. November 2004, 17:05   #7
Senior Member
 
Registriert seit: 06.10.2003
Beiträge: 300

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
Rumpelzuck ist offline   Mit Zitat antworten
Alt 2. December 2004, 18:52   #8
MODder
 
Benutzerbild von Xman
 
Registriert seit: 28.03.2003
Beiträge: 5.800

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)
__________________
Xman ist offline   Mit Zitat antworten
Antwort

Lesezeichen

Themen-Optionen

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are an


Ähnliche Themen: Wie wird die übertragene Rate eigentlich ermittelt??


  1. wie funktioniert rapidshare eigentlich?
    Filesharing - 28. April 2012 (2)
  2. wie erhöhe ich die download rate bei utorrent?
    Filesharing - 24. April 2011 (2)
  3. wie krieg ich die kb/s rate bei utorrent hoch?
    Filesharing - 16. October 2010 (2)
  4. wird da eigentlich auf die "großen Fische gesetzt?
    Filesharing - 19. February 2010 (2)
  5. wie funktioniert eigentlich die ganze sache mit dem downloaden bei rapidshare?
    Filesharing - 12. September 2009 (2)
  6. Wie ist eure Download rate ?
    Mülltonne - 13. September 2006 (6)
  7. Wie ist eure Download rate ?
    Mülltonne - 13. September 2006 (0)
  8. LowID Problematik: Wie wird die ID errechnet?
    eMule Allgemein - 15. April 2006 (1)
  9. Übertragene Datenmenge geringer als Dateigröße?
    eMule für Neulinge - und auch alte Hasen - 19. January 2005 (3)
  10. Was ist das eigentlich, die GNU General Public License ?
    Allgemeines OffTopic - 11. December 2003 (0)
  11. Wie wird meine IP-Adresse ermittelt?
    eMule Allgemein - 8. October 2003 (5)
  12. Wie/woraus ergeben sich eigentlich die Memberlevel?
    Allgemeines OffTopic - 19. March 2003 (4)


Alle Zeitangaben in WEZ +1. Es ist jetzt 01:18 Uhr.


Powered by vBulletin® Version 3.8.3 (Deutsch)
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
SEO by vBSEO ©2011, Crawlability, Inc.
PAGERANK