Laut Firewall hat emule einen Upload von schwankend zwischen 24kb/s und 28kb/s. Davon sind aber laut emule nur etwa 22kb/s wirklich Nutzdaten, d.h. der Anteil an Overhead schwankt zwischen 9% und 27%, wobei es meistens im 20er Bereich liegt.

War mit früher nie so bewusst geworden, aber ich frage mich mittlerweile ob es sich da überhaupt lohnt Kad zu aktivieren, denn schalte ich Kad aus steigt der von USS geregelte UL von 22 auf 25.5kb/s im Schnitt. Insgesamt scheint mir 3.5kb/s mehr Upload (immerhin ein Slot) sinnvoller als die Kadunterstützung.


Natürlich kann es passieren dass irgendwann kein Weg mehr um Kad herumführt, falls Server rechtlich belangt werden, aber solange opfere ich ungern 3kb/s dafür. Meine Frage, gibt es überhaupt noch Spielraum irgendwie den Overhead bei Kad zu reduzieren, oder muss man damit leben?

Und wie ist das bei anderen, ebenfalls so starker Overhead? Ich habe meist so zwischen 600 und 700 Kontakte.


Achja und noch eine Sache, ist zwar altbekannt, aber warum zeigt emule nie den wirklichen Traffic an den es verursacht?

server aus nur kad oder nur server aber kein kad

najo die overhead anzeige könnte mal verbessert werden stimmt schon
jedenfals kann es nicht angehen das es 0.x kb sind wie angezeigt
wenn ich ein limit von 12 einstelle aber es nicht mehr als 11 rausbringt
ohne kad sind dann auch schon mal 14 oder 15 drinn

Bei meinem Standard-DSL-768 würde der KAD-Overhead auch 'nen ganzen Upload-Slot verballern und ich kriege kaum zusätzliche Quellen darüber -> z.Z. KAD aus bei mir

Ich hatte Kad immer an weil ich dachte wer weiss ob man nicht doch die eine oder andere Quelle für seltene Dateien nur darüber findet (und ausserdem probier ich immer gern alles neue aus ). Aber auf Kosten von 3kb/s UL machs ich nun doch nicht unbedingt...

Ich weiß nicht, was ihr falsch macht, aber ich hatte vor und nach Kad 27k up (QSC).
Und da Kad unkaputtbarer als ein Panzer ist unterstütze ich dieses System sehr gerne.

Endich ist eMule ein echter P2P Client. Man müßte es jetzt nur noch schaffen dynamische chunk großen wie bei bittorrent einzuführen. Dann müßte man nicht immer 6 Stunden warten bis das erste Byte dahertröpfelt sondern der download würde sofort mit vollem upload speed starten.

32k chunks bei 5MB Dateien ist einfach unschlagbar!

Wann wird das Netz endlich migriert? eMule hätte mit seiner user base eine sehr gute Chance die Vorteile beider Netze (emule - ein Netz und bittorrent - dynamic chunks size) zu vereinen.

also bei mir braucht auch das kad nicht mehr wie 1kb/s im betrieb beim start natürlich mehr. aber bei mir ist kad sehr wichtig den ich saug viele alte datein die kaum leute haben und meist finde ich dort am ehesten was und die quellen kommen bei mir auch meist über kad am schnellsten.

vielleicht hat einer von euch so ne gute anbindung das er das teil dann als "kad-server" (grad verplant wie die teile bei kad heißen) benutzt.




wegen den chunk größen moonlight hatte da mal was in der mache hab aber schon lange nichts mehr davon gehört. sein system sollte dynamische chunks zwischen einigen kb und ich glaub 16mb ermöglichen.
allgemein wurden kleine chunks meist wegen des hohen overheads für die anfrage usw. abgelehnt.
das beste währe sowie so wenn man nur noch nen warteschlangenplatz bekommt aber dann fallen so sachen wie dateien pushen sprich die einzelnen prioritäten weg. aber das würde verdammt viel overhead sparen. viele clients und user swappen ja schließlich immer zwischen den einzelnen dateien die quellen hin und her (bis sie gebannt werden trotzdem schwachsinn schließlich könnte der user nen super upload haben und das file dann masiv pushen.

Das ist eben ein kleiner Nachteil von KAD. Da es keine Server gibt, spielt eigentlich jeder im KAD-Netzwerk einen "kleinen Server", welcher die Quellen weiterleitet muß.

Das mit den 3 KB/s Overhead kommt bei mir auch etwa hin (11 wird bei eMule angeziegt ca. 14 KB/s am Router). Dafür das dieses Netzwerk kaum angreifbar ist würde ich den höheren Overhead in kauf nehmen.

Mit den ed2k-Servern hat man vielleicht nicht so einen hohen Overhead, falls es aber mal keine mehr geben sollte, hat man auch nichts davon.

Außerdem befindet sich das KAD-Netzwerk in eMule noch in der Entwicklungsphase und das Overhead-Problem wurde glaub ich bereits auf die TODO-Liste der Devs gesetzt. Einfach abwarten was sich die Devs da einfallen lassen. Wäre ja nicht das erste mal wo sie uns positiv überraschen.

Der Overhead ist bei 32kiB Chunks auch nicht sehr groß.

16 Byte(Hash)/32768 = 0,05%

Dazu kommen noch je nach Größe der Datei ein paar Byte meta Informationen.

z.B.: bei 6GB Datei
6'000'000'000/32'768 = 183106 Chunks

Pro 32768 Byte Chunk werden noch ein paar Byte für den Chunk Info Exchange benötgt.

32kiB Chunk mit Chunk Info Exchange:

[HaveChunksStart]78374[/HaveChunksStart]
[HaveChunksEnd]78434[/HaveChunksEnd]
[Chunk]82374[/Chunk]
[Data]32768[/Data]###32kiB unquoted Data

[HaveChunksStart]6784[/HaveChunksStart]
[HaveChunksEnd]6784[/HaveChunksEnd]
[Chunk]345[/Chunk]
[Data]32768[/Data]###32kiB unquoted Data

[HaveChunksStart]17763[/HaveChunksStart]
[HaveChunksEnd]17769[/HaveChunksEnd]
[Chunk]123876[/Chunk]
[Data]32768[/Data]###32kiB unquoted Data
...


das verbraucht mit Byte quote nochmal für
[HaveChunksStart] -> 1 Byte
78374 -> 3 Byte (quoted, kann natürlich auch mehr sein)
[/HaveChunksStart] -> 1 Byte
[HaveChunksEnd] -> 1 Byte
78434 -> 3 Byte (quoted)
[/HaveChunksEnd] -> 1 Byte
[Chunk] -> 1 Byte
82374 -> 3 Byte (quoted)
[/Chunk] -> 1 Byte
[Data] -> 1 Byte
32768 -> 3 Byte (quoted)
[/Data] -> 1 Byte
Die folgenden 32768 Byte ist der Chunk Nr. 82374. Die Daten werden logischerweise nicht mehr gequoted, da vollkommen klar ist, das die nächsten 32768 Byte der Chunk ist.

Das ganze mal gesprochen:
Hallo, hier kommt der Chunk 82374! Er hat eine Länge von 32768 Byte. Ich habe übrigens auch noch die Chunks 78374 bis einschließlich 78434!


in diesem Beispiel kommen also nochmal 20 Byte dazu.

Mach Summa Summarum:

(16+20)/32768 = 0,1% Overhead

Außerdem kann man den source exchange auch locker damit abwickeln.


32kiB Chunk mit Source Exchange und Chunk Info Exchange:

[HaveChunksStart]78374[/HaveChunksStart]
[HaveChunksEnd]78434[/HaveChunksEnd]
[IPv4SourceExchange]192.168.0.1:1111[/IPv4SourceExchange]
[Chunk]82374[/Chunk]
[Data]32768[/Data]###32kiB unquoted Data

[HaveChunksStart]6784[/HaveChunksStart]
[HaveChunksEnd]6784[/HaveChunksEnd]
[IPv4SourceExchange]192.168.0.2:1111[/IPv4SourceExchange]
[Chunk]345[/Chunk]
[Data]32768[/Data]###32kiB unquoted Data
[...]

macht:

[HaveChunksStart] -> 1 Byte
78374 -> 3 Byte (quoted, kann natürlich auch mehr sein)
[/HaveChunksStart] -> 1 Byte
[HaveChunksEnd] -> 1 Byte
78434 -> 3 Byte (quoted)
[/HaveChunksEnd] -> 1 Byte
[IPv4SourceExchange] -> 1 Byte
192.168.0.1:1111 -> 6 Byte (quoted)
[/IPv4SourceExchange] -> 1 Byte
[Chunk] -> 1 Byte
82374 -> 3 Byte (quoted)
[/Chunk] -> 1 Byte
[Data] -> 1 Byte
32768 -> 3 Byte (quoted)
[/Data] -> 1 Byte

Das ganze mal gesprochen:
Hallo, hier kommt der Chunk 82374! Er hat eine Länge von 32768 Byte. Ich habe übrigens auch noch die Chunks 78374 bis einschließlich 78434 und kenne die Source 192.168.0.1:1111


Mach Summa Summarum:

(16+20+8)/32768 = 0,1% Overhead
--> bei 16kiB up sind das gerade mal 16kiB*0,001 = 0,02k

Wie man sieht kann man da auch noch jede Menge anderer Informationen hineinpacken, ohne das der Overhead nennenswert steigt. Und das beste: Da das ganze ja praktisch ein XML auf Byteebene ist läßt sich jede Information beliebig oft hintereinader oder auch gar nicht übertragen. Das spart erstens Traffic und ist zweitens vollkommen ohne limits.
Außerdem läßt sich ein solches Protokoll auch ohne weiteres erweitern. Man führt einfach einen neuen Tag ein. Für alte Clients unbekannte Tags werden einfach ignoriert. Es sind maximal 254 Tags möglich (256 - [Ende-Tag(/*)] - [Quote-Byte]). Das sollte reichen!

z.B.

2 x SourceExchange mit einen 32kiB Chunk und File Comment:

[IPv4SourceExchange] -> 1 Byte
192.168.0.7:1111 -> 6 Byte (quoted)
[/IPv4SourceExchange] -> 1 Byte
[IPv4SourceExchange] -> 1 Byte
192.168.0.6:1111 -> 6 Byte (quoted)
[/IPv4SourceExchange] -> 1 Byte
[Comment] -> 1 Byte
"Die Datei ist absolut toll!" -> 27 Byte (Unicode (UTF-8), quoted)
[/Comment] -> 1 Byte


Das ganze mal gesprochen:
... und kenne die Sourcen 192.168.0.7:1111 und 192.168.0.6:1111. Außerdem hat ein User folgenden Kommentar zu dieser Datei abgegeben: "Die Datei ist absolut toll!"


Solche Dinge wie:
Da kann man nur 4 Zeichen eintragen! Warum? Weil das Feld im Protokoll nicht mehr Platz vorsieht!
... gehören der Vergangenheit an.

eMule scheitert derzeit kläglich aus genau diesem Grund am 4GiB (4Byte Integer) limit.

Ein Credit System wird auch noch praktisch kostenlos mitgeliefert.
--> Ich geb dir einen Apfel - du gibst mir einen Apfel

Im Moment läuft es so:
Ich geb dir einen Schubkarren Äpfel (9,28MiB) und wenn ich Pech habe bekomme ich nichts zurück.

Und auf Dinge wie 'secure Identification' und Client IDs kann man ebenfalls verzichten, da es dafür dann keinen praktischen Nutzen mehr gibt.

Vorteile:
- Kein limit: Dateien können wirklich beliebig groß sein - nicht nur 4GiB
- Sehr einfaches Protokoll
- Praktisch überhaupt kein Overhead
- Keine Wartezeiten. Download startet sofort.
- Unendlich gerecht
- Leechen unmöglich

Nachteil:
- CPU und Memory intensiver

Allerdings ist es auch sicher übertrieben 6GB in 32kiB Stückchen zu zerhacken.
Sinnvoller wäre hier sicher eine Chunk Größe von 6GB/10'000 aber mindestens 32kiB o.ä.

Nur leider verwendet eMule nicht dieses Protokoll, aber ich bin mir sicher das es die nächste Generation eines P2P Netzwerkes genau so machen wird.

toll mal ein

Denk mal drüber nach

thread,

nochmal, wenn jemand mit einer t3 leitungs ins netz kommt. und der genau gleich viel zurück bekommt wie er gibt, somit gäbe es ein 1:1 ratio. ich hätte nichts gegen ein 1:1 ratio, denn dann hätte ich immer meine 21 kb down. jedoch wollen ja alle 10 kb ul geben und 100 kb down. also heist das das leute mehr geben als nehmen und andere mehr nehmen als geben, und schon lechen die wo über 1:1 haben. somit wäre file trading der tot aller p2p börsen. den mir machts nichts aus ob ich jetzt ein 2:1 ratio habe oder tiefer. und file tauschen...... wie kann man überwachen? mit einem cs..... nein! mit horde ....... nein! man kann file trading gar nicht durchführen. den für das bräuchte man einen zentralen server.

also denkt mal ........ ach lassen wir das

PS: obwohl mein erstes post schon etwas anderes angeschnitten hat, möchte ich bitten das wir beim thema bleiben (overhead bei kad) und ich geb auch zu das ich derjenige war der vom thema abgekommen ist

begin
Diesen Quatsch mit der 1:2 Ratio und dem Leechen kann ich nicht mehr hören. Das ist ein totaler Unsinn! Im Grunde genommen ist das zwar logisch gedacht, aber eben nicht praktisch erprobt. Solange man mit mehr als 1:1+ saugen kann, muß die Bandbreite zur Verfügung stehen, also irgendwo herkommen. Wenn damit einzelne die Bandbreite der anderen wegnehmen würden, dann würde das Board hier von "Buhuhu, mein Muli läuft nicht *heul*" Threads überquellen. (Und sag jetzt bitte nicht, dass das doch so ist...)

Und wo kommt sie her? Natürlich genau von den Releasern mit riesiger Bandbreite. Denn wenn man an einer dicken Leitung sitzt, kriegt man niemals im Leben eine 1:1 Ratio zustande. Das kann gar nicht gehen, soviele Verbindungen kriegt man gar nicht geöffnet, wenn nur "kleine" mit 3-4 kB/s uploaden!

Und praktisch habe ich diese Erfahrung gemacht: Wenn ich in die Uni gehe und dort mal locker mit 1400 kB/s und mehr hochlade, dann komme ich am Ende auf eine Ratio von 10:1 bis 8:1, wenn alles gut läuft. Und genau diese Transfers sind es nämlich, die es möglich machen, dass die meisten eine höhere Ratio als 1:1 erreichen können. Und nicht, weil sie anderen geklaut wird.

Deshalb halte ich dieses dauernde 1:1 Geschrei für absolut überflüssig und schädlich für das Netzwerk.
end

naja dann gleiten wir halt vom thema ab (mir ist es egal )

du beschreibst ja das wo ich sage, file trading heist jedoch das auch der wo mit (wie du gesagt hast) 1400 raufläd ein recht auf 1400 hat. und somit würde ein 1:1 ratio entstehen, weill natürlich alle ihre "credits" einlösen wollen. file sharing heist das es leute gibt die mehr hochladen als downladen. und die dafür nichts wollen.

wegen dem 1:1 ratio, ich hab nur gesagt das ich froh wäre wenn ich immer eins hätte (eben hätte). ich sagte nicht ich will ein 1:1 ratio für alle user. und sorry leute die mehr runterladen als rauf sind leecher. den ab 1:1 fängt das leechen an. ich sag ja nicht das es schlimm ist aber wenn ich (vor 1 und halb jahren war es so schlimm) von user höhre ich gebe 10 kb ul und bekomme nicht mehr 80 kb down, das find ich schlimm. aber bei ratios bis 1:3-4 kann gut vorkommen (durchschnitt)

Das stimmt, diese Typen sind lächerlich. Wobei ich mich frage, wie die überhaupt 80 k hinbekommen. Seitdem ich den Muli (zu Hause) benutze, ist mir so eine hohe DL-Rate vielleicht 3mal untergekommen.
Wogegen ich was habe ist, dass du (u.a.) mich als Leecher bezeichnest, weil ich (auch wieder zu Hause ) mit einer Ratio zwischen 1:1,5 und 1:2 sauge. Das ist lächerlich...

die definition von leecher ist recht schwer zu sagen, ab wann leecht man? bei 1:1.1 oder bei 1:100 ? da sind die meinungen verschieden. darum fängt meine definition an bei 1:1,x obwohl das ja noch nicht schlimm ist.

das mit den 80 kb down und den 10 kb up gabs viel als emule, damals noch ein leecher client war, und die 0.60/1 edonkey's ausgesaugt hat. damals gabs ohne probleme 80 kb down mit 10 up. jedoch wechselten dannach so viel auf emule, sodas der dl natürlich wieder in den keller ging respektive auf das gleiche niveau wie vorher da es fast keine edonkeys mehr gab. das problem war nun aber das viele das forum hier überschwemt habem mit:

ÄÄÄÄÄÄÄH BLÄR SCHLUCHTS HEUL BEKOMME NUR NOCH 40 KB DL, FRÜHER WAREN ES 80 KB BLÄR SCHLUCHTS

was ihr euch aufregt
am ende habt ihr das file und nur das zählt
ob es nun ein paar tage länger dauert oder nicht
im übriegem leechen ist ein meinen augen nur nehmen und nichts geben

Um nochmal kurz zum Thema zurückzukommen...

Natürlich weiss ich dass Kad grosse Vorteile ggü einem serverbasierten Netzwerk hat und dass diese auch 3kb/s UL aufwiegen würden. Aber solange die Server reibungslos laufen, warum dann 3kb opfern?

Ich sage ja nicht Kad an sich wäre schlecht, nur in der momentanen Situation sehe ich noch keinen Grund es unter der Prämisse dass der Overhead so hoch ist einzusetzen.


Und zum Thema Leecher,

ein Leecher ist für mich jemand der extra nichts oder nur sehr wenig hochlädt, sich im Download aber ohne Grenze bedient. Auf was für eine Ratio der dann im Einzelfall kommt ist doch unerheblich.

Die Frage wo die Bandbreite herkommt mit der manche runterladen denke ich kann man nicht klar beantworten. Ein Teil wird von Releasern (oder normalen Usern mit dicker Leitung wie US-Campus) kommen und ein Teil aber auch von den Usern die eben UL > DL haben. Bei mir ist die Ratio auch nur etwa 1,2:1 - das muss ja irgendwo verschwinden.

Ist ja klar, wenn einer mehr hochlädt als runter, dann haben andere mehr down als up. Desshalb sind sie keine Leecher.

Was mich aber immer ärgert:

Bei bittorrent bekomme ich immer in etwa das was ich hochlade. Einmal sogar 600MB in 3 Minuten. Allerdings habe ich in der selben Zeit auch ca. 300 MB hochgeladen.

Bei eMule lädt man 10 Minuten lang mit 3MB/s hoch (1,8GB) und bekommt in der Regel überhaupt nichts, was natürlich zur Folge hat, das Leute mit schnelleren Leitungen eMule meiden.

Bittorrent
Nachteil: nicht durchsuchbar
Vorteil: schnelles Protokoll

eMule
Nachteil: super langsames Protokoll
Vorteil: durchsuchbar

Man müßte es jetzt nur noch schaffen beide Vorteile in einem der beiden Netze (oder besser in einem neuen Netz) zu vereinen. Es ist technisch ohne Probleme machbar, nur tut es keiner. Warum?

Ich kann mich über den Overhead (Kad & Server) nicht beschweren:



Blau = Overhead sent / Grün = Overhead receive

Liegt vielleicht an dem Mod, den ich verwende

Gruß, Foxbat

@Bug:

Mein Log-Zeit Problem habe ich leider nur durch "Format c:" gelöst.

Der Mod vom Doc ist halt doch der Beste.

Aber den benutze ich gerade nicht.

Ich habe leider keine Info ob "MuleMRTG" beim Overhead extrem ungenau ist.

Gruß, Foxbat

es liegt eher dran das im bittorrent die haltezeit für fles nicht so hoch ist,
ed2k ist bekannt für die "haltbarkeit" der dateien.
versuch mal mit bittorent ein "backup" was du vor 2 jahren ins netz geschoben hast zurückzusaugen. bei ed2k weiss ich das es geht *proved*.

natürlich nicht alle files, aber einige halten sich wirklich sehr gut

daraus ergibt sich auch das du in warteschlangen länger anstehen musst. BT wird mit wachsendem content genauso unter der geschwindigkeit leiden, wobei diese art wachstum vom entwickler gar nicht vorgesehen ist/war.

ich hab nochnicht erlebt das mit emule mein upload idled ausser vielleicht beim allerersten start
ausserdem frag ich mich wie mann so von zuhause mit dsl oder so mal eben 10gb geben soll

sieht so aus als ob emule für dich nicht die ideale wahl ist, nimmst halt bt macht doch nix

@biberl,

mit deiner Leitung wär die FXP-Scene woll die beste Lösung, du könntest ja uppen wie keiner Und wenn du dann dabei bist, hast du auch ein ziemlich anständiges Angebot

Filesharing ist doch kein Wettbewerb. Ist doch total egal ob ich etwas in 3 Tagen oder in 3 Wochen auf meiner Platte habe und wenn's doch schneller gehn muss fahr ich einfach in die Stadt.

falsch ! dann leidet der content. bei dem grossen angebot geht es mit keinem optimiertem protocol der welt schneller. die chunkgrösse ist dabei nebensächlich, ich versteh echt nicht wie man sich daran so hochziehen kann.


das ändern dieser werte zieht entweder eine inkompatibilität zur jetzigen filebase nach sich.... toll, kann man gleich ein anderes netz nehmen, oder wie man im Horde Fall sieht
wo die chunks nochmals geteilt werden, erhöhtes corruptionaufkommen durch nicht verifizierte crumb hashes. dem war so weit ich weiss im 53er donkey nur beizukommen indem rigoros auf sharing von nichtkompletten chunks verzichtet wird....damit ist aber der von dir geforderte enorme vorteil wieder dahin.

bei den chunks stimmts schon, würde das protokol 256 chunks zulassen, (theoretisch) müsste man manchmal nicht irgendwie 3 stunden warten bis man mal eins komplet hat zum raufladen

biberl

hast du schonmal überlegt was das edonkey netz für eine vielzahl von dateien hat?

bei bittoront geht es nur so schnell weil alle an dem gleichem file laden was beim emule nicht der fall ist ...
normal ist das bittoront netz mit dem edonkey nicht vergleichbar edonkey ist ein netz
bittoront sind viele kleine netze