MTU maximum transfer unit
 

MTU
Die MTU (Maximum Transmission Unit) beschreibt das für ein Medium (oder Protokoll) größtmögliche Paket. Die MTU spielt vor allem bei der Fragmentierung eine wichtige Rolle.

Fragmentierung
Zerlegung eines Datenpaketes in mehrere kleine Teile (Fragmente). Dies wird z.B. dann nötig, wenn ein Paket größer ist, als die MTU des Netzes. Die Fragmentierung wird i.a. durch Router vorgenommen.

Überblick über die MTU wichtiger Layer 2-Protokolle



Token Ring 16MBits Bit: 143928 byte: 17997
Token ring 4MBits Bit: 36008 byte: 4501
Ethernet Bit:12144 Byte:1518
x.25 (maximum) 8192 byte: 1024
x.25 (standard) 1024 byte: 128

Hier mal ne kleine Ergänzung von mir (kopiert von hier):Jetzt noch ein paar Anmerkungen, wie sich die Änderung der MTU auf welche Werte in Emule niedergeschlagen hat, wäre nicht schlecht. ;-)

1492 übermäßig viele verbindungsabbrüche
verringerung der MTU - verringerte verbindungsabbrüche
keine weitere selbst bemerkbare verringerung der verbindungsabbrüche unterhalb von 1448

verbindungsabbrüche hier: nicht zustandegekommene uploads oder/und downloads, oder verbindungen die zu 0 schrumpften und dann abbrachen (timeout, nicht in statistik vorhanden, einzig lokal visuell persönlich einsehbar)


ausserdem hohe MTU vom server angegebene quellen wurden nicht innerhalb des timeouts abgefragt.
dieser wert ist sowohl bei einer zu hohen MTU, als auch bei einer zu niedrigen MTU feststellbar. eine optimale MTU resultierte bei mir in einer optimalen quellenabfrage.

bedeutet: nach der kontaktierung eines servers war mein muli mit mehr quellen in verbindung getreten und hatte warteschleifen betreten, als bei einem falsch eingestellten MTU

Mmh, hab mal ein bischen gestöbert, in 2000/XP gibt es eine integrierte Funktion, die automatisch die optimale MTU für einen anderen Server/Rechner ermittelt. Wußte ich gar nicht, aber die hast du bestimmt ausgestellt. Vielleicht wird die auch automatisch deaktiviert, sobald man einen MTU-Wert vorgibt.

Ich hab noch folgende interessante Möglichkeit gefunden: h**p://www.emuleforum.net/archive/topic/16504-1.html

Nach der Methode und mit heise online als Server habe ich herausbekommen, das ab 1460 nicht mehr die Pakete fragmentieren muß. Allerdings habe ich keinen Weg gefunden, wie ich herausbekomme, welchen Wert Windows benutzt, wenn man die MTU nicht festlegt, sondern die automatisch ermittelt.

interessante frage. die werte von hause aus sollen angeblich (laut diverser tools wie DFÜ Speed... vom standard her eher bei ISDN liegen)


darkwolf
t-dsl 1500 ..nunja... da muss man erstmal 8 abziehen die grundsätzlich reserviert werden müssen... deswegen ergibt sich ein maximalwert von 1492 für tdsler...aber wie sieht das aus bei 1500... ist ja auch tdsl ... ist der wert da gleich ?

nun... richtig ist... dass die änderungen beim DL und UL was bringen... nun frage ich mich allerdings.... wird sourceexchange etwas nicht runter und hochgeladen ?


ausserdem frage ich mich.... ich denke mal ein paket hat ja eine gewisse mindestgröße... wenn die information kleiner ist ...dürfte eine art platzverschwendung entstehen wie auf Festplatten (Dos User auf FAT16 wissen garantiert was ich meine) ... jetzt die frage... welche informationen sind denn in einem austausch paket von source ex drin... und wie groß sind die? .... dass die erstmal gesendet und auch empfangen werden müssen, und dann vor ort ausgewertet werden müssen, erschien mir bisher als klar.

mein explorer muss ja daten auch erstmal runterladen bevor er sie anzeigen kann.

Ein TCP/UDP-Packet hat doch eine feste Größe. Weniger als ein Paket kann man nicht verschicken. Wenn man mal sich darauf versteift, das bei den üblichen Anschlüßen die Nutzlast 14xx beträgt, kann man doch ganz gut rechnen.

Was ist eine Quelle? Normalerweise ist doch eine Quelle nichts anderes als eine IP (4 Bytes) und ein Port (2 Byte), unter dem ein Emule erreichbar ist, der mir als Quelle dienen kann. Zusätzlich brauche ich noch die Angabe, für welche Datei die Quelle gelten soll. Wenn ich jetzt jemanden nach Quellen frage, ist doch das Anforderungpaket praktisch total leer, neben etwas Overhead (was ist das für ein Paket) und dem Dateihash (32 Byte, oder? Edit: Nein, es sind nur 16 Byte, hab mal nachgeschaut) der gewünschten Datei ist ja nicht viel weiter drin -> passt locker in 14xx Byte. Die Antwort beinhaltet auch wieder etwas formaler Kram, unter anderem die Datei/Dateihash, für den die Quellen gelten. Und natürlich die Quellen. Wenn wir jetzt mal annehmen, das in einem SE-Paket 1200 Bytes für Quellen übrig bleiben, könnte man darin 200 Quellen unterbringen.

Meine (zugegebenermaßen gewagte) Theorie: Ein SE-Vorgang besteht aus genau zwei Paketen, eins zum Anfordern, eins zum Quellen empfangen.

Hat jemand den Wert im Kopf, wieviel Quellen maximal bei einem Source Exchange Vorgang übertragen werden? Ich bilde mir ein, es waren weniger als 200.

Da fällt mir noch was zum optimieren ein, vielleicht ist das ja auch der Fall. Das Problem ist doch immer, das ich immer Quellen bekommen, die ich schon habe. Wie wäre es mit der Erweiterung: wenn ich Quellen anfordere, sende ich im Request soviele Quellen wie möglich mit (die ich schon habe), ob das Paket halb voll ist oder voll, macht ja keinen Unterschied. Das hat zwei Vorteile:

1. Der andere bekommt ungefragt Quellen. Ob er sie benutzt oder wegwirft, ist ja seine Sache, es schadet wohl nicht.

2. Der andere kann die Quellen, die er mir schickt, vorselektieren, Quellen, die in meinem Paket schon drin sind, braucht er mir nicht nochmal schicken.

Irgendwie kommt mir das so simpel vor, das es eigentlich schon implementiert sein müßte. Oder hab ich was übersehen, was dem entgegensteht? Ist aber bestimmt schon im Emule drin, wenn nicht, dann HALLO MODDER :mrgreen:

dann wirds in jedem falle ein TCP Paket, oder ? mit UDP Request ist dann nixmehr, da einmal hin und an die gleiche IP wieder zurückgehen soll ?!


wie kommst du eigentlich auf IP 4 bytes port 2 bytes ??
soweit ich weiss ist EIN ZEICHEN = 1BYTE ?! schreib doch mal mit nem editor ein paar zahlen und zeichen auf. die txt hat dann genausoviel byte wie zeichen sind

wenn ich mir jetzt überlege, dass also für jede quelle eine paketeinheit draufgeht...

in den meisten windows ist eine beschränkung für 3 ladevorgänge gleichzeitig, dazu dürfte auch emule gehören

Wieso TCP? Ein UDP-Paket zur Anforderung, eines dann, wenn man die Quellen bekommt. Dazwischen braucht keine Verbindung zwischen den Rechnern bestehen. Wenn der andere keine Quellen hat, kommt einfach nichts zurück.

Eine IP ist doch sowas 192.168.11.16, wobei jede Zahl zwischen 0 und 255 sein kann. 2^8 ist 256, also braucht man für eine Zahl zwischen 0 und 255 genau 8 Bit, also ein Byte. Da eine IP aus 4 solchen Ziffern besteht, sinds halt 4 Byte.

So ähnlich ist es beim Port. Ein Port ist eine Zahl zwischen 0 und 65535, das kann man mit 2^16=65536, also 16 Bit darstellen. Und das sind 2 Byte.

Meiner Meinung nach frage ich bei jemanden nach Quellen -> 1 Paket. Dann bekomme ich eventuell irgendwann eine Antwort mit max. 200 Quellen darin (so meine Beispielrechnung ob, praktisch sind wohl weniger drin) -> 1 Paket. Also gehen nicht pro Quelle eine Paketeinheit drauf, sondern für 200 insgesamt. Oder halt 1/200stel Paket pro Quelle.

Was hast du da wieder aufgenschnappt? Die einzige Begrenzung in die Richtung ist wohl die, das bei HTTP 1.1 (oder nem anderen Standard, bitte nicht hauen deswegen) definiert ist, das ein Client (bei http z.B. der Browser) maximal 2 Verbindungen gleichzeitig zu einem Server haben darf. Aber diesen Wert kann man total einfach ändern, bei Opera ist sowas schon eingebaut, beim IE muß man wohl die Registry bemühen. Aber wie gesagt, gilt nur für HTTP. Wenn es noch ne andere Begrenzung gibt, lasse ich mich gern belehren, kann ich mir aber nicht vorstellen, weil das für Server eher suboptimal ist ;-) Mal nebenbei, was ist bei dir eigentlich ein Ladevorgang?

ok, ist mir im grunde nicht bewußt gewesen... aber eigentlich logisch, dass die ports hexadezimal gesendet werden.


bezüglich der 3 loads.... ok ... mag sein dass sich das auf http begrenzte... wo aber ist dann die begrenzung für die anderen ? ich meine kann doch nicht unendlich netzwerkverbindungen geben, oder ?

also hier mal aus den faq's:
cyrex2001
ps:

Ich denke schon, das es irgendwo eine theoretische Begrenzung geben wird, aber die ist wohl für unsere Betrachtung nicht von Bedeutung. Bei mir ist zum Bespiel mein Rechner an mit einer 10MBit-Karte an den Router angeschlossen, übers Internet kommen nunmal maximal 786kbit/128kbit rein bzw. raus, es wäre schlimm, wenn ich damit die 10MBit-Karte an ihre Grenzen bringen würde. Außerdem gibt es für Win2000/XP 1GBit-Karten, die man auch noch mehrfach im Rechner haben kann, es wäre schlimm, wenn man da ein Limit hätte, das uns interessiert. Momentan wird die maximale Verbindungszahl wohl eher durch unsere Internetanbindungen praktisch begrenzt als durch eine künstliche Grenze irgendwo im System.

Praktisch wird es doch wohl auf sowas hinauslaufen: Mal angenommen, jede Verbindung hat eine Kennnummer. Wenn man diese Kennnummer nun 2 Byte groß gewählt hat, kann es nie mehr als 65536 gleichzeitige Verbindungen geben -> theoretisches Limit, was wohl momentan kaum von Bedeutung wäre. Keine Ahnung, ob es eine solche Begrenzung gibt.

Mich würde viel eher mal interessieren, wo die Limits herkommen, die wir so beobachten, von Windows ja wohl nicht (mal abgesehen von 98). Gibt es Limits beim Modem, bei der Telekom oder wo?

cyrex2001,

ja, das habe ich auch gelesen, allerdings steht an anderer Stelle Scheinbar wiederspricht sich die Dokumentation hier etwas.

Quelle: http://www.emule-project.net/faq/de_pref_connection.htm

meine quelle: http://www.emule-project.net/faq/de_source.htm stand: 4.05.2003 *grübelundhaarrauf*
cyrex2001

Usul, ich glaub deine quelle scheint wohl doch die aktuellere zu sein!meine: aber immer noch nicht ganz sicher! :?: :?: :?:
cyrex2001

cyrex2001,

hab ich auch gesehen. Dummerweise weiß man ja nicht, was sie da geändert haben, nen Changelog für die FAQ gibts wohl nicht :lol: Ich hab gerade versucht, in den Changelogs von Emule was dazu zu finden, aber ohne Erfolg :-(

Usul, ich kann mich entsinnen, dass in einer 23er oder 24er der udp-port nicht eintragbar war!
cyrex2001

ich denke, das windows eben für Internetanbindungen, also solche die ein modem in irgendeiner form zugrunde haben, sehr wohl in der registry beschränkungen festlegt... das zeigen jeweils tuningprogramme diverser art an.

die theoretischen verbindungen fürs netzwerk sind aber eigentlich für die i-netleitung wieder nicht interessant...


du hattest jetzt bei 200 quellen die man weitergibt plus hash plus allem drum und dran auf 1kb gerechnet, oder ? ... pro user der abfragt. bei wombat also nach meiner berechnung von 200 usern von vorhin also alle 2,5 sekunden ein kb. pro sekunde gerechnet also 0,4 kb.

hmm. hatte sich irgendwie alles anders bei mir ausgemmacht...ok, dann sind das die overheadzahlen.


meimei... auf jeden fall hat gvstarfleet bei 600 verbindungen mit T-DSL irgendwie trotzdem ziemlich krass overhead.

zumal... sind verbindungen queueplätze wo er wartet ? oder up und downloads ?

ich hab gerade 17.
5 uploads 5 downloads...aber wesentlich mehr quellen...was also ist eine verbindung ?

Langsam ist es irgendwie witzig, das wir anhand von eWombat (damit hat ja alles angefangen) so auf statistischen Werten rumackern, und eWombat ausgerechnet die magerste Statistik hat. Bei anderen Mods gibt es wohl nen extra Statistikwert für den Trafficverbrauch von Source Exchange, der würde wohl einiges klären.

meinst du so etwas?
eMule v0.29c sivka v9b2b [Athlazan]v2.15c [Gnaddelwarz v1.1a] Statistics [Renegade]

Session
Hochgeladen: 383,11 MB
Totaler Overhead (Pakete): 9,14 MB (201K)
Overhead durch Quellenaustausch (Pakete): 1,80 MB (1K)

Session
Heruntergeladen: 195,52 MB
Totaler Overhead (Pakete): 7,49 MB (185K)
Overhead durch Quellenaustausch (Pakete): 1,16 MB (2K)

durchaus... Laufzeit dazu ?

renegade,

ja genau, das meine ich. Scheint ja extrem wenig Overhead zu sein im Vergleich zu den anderen Werten. Über welchen Zeitraum ist diese Statistik (ungefähr reicht ;-) )?

201K heißt ja 201000 pakete oder ?

cyrex2001,
bin froh, daß ihr diese Quellen mal gepostet habt, nachdem ich mir an MxM heut die Zähne ausgebissen hab. :mrgreen:
Also das Sourceexange geht denk ich schon über UDP. Denn ich verfolg ja öfter mal mein Log und da steht dann immer UDP-Request sources blabla irgendwas.

ich bin halt ein schwarz auf weiss typ.... oder du musst schon sehr gut argumentieren. mit einem zweizeiler lass ich mich meist nicht abspeisen... und wenn die gegenargumente sich genauso nach vermutung anhören wie ich das mache, da kann ich mir meist das zuhören sparen.

ich bin in zeiten in foren gekommen, da waren postings in der länge wie meine normale, weil man sich noch per 14.4 modem connected hat zur box seiner wahl. da kam man nur 2x in der woche an einen offenen port, und da hat man dann dementsprechend postings mit inhalt erwartet und auch geschrieben.

ich hab das problem, dass ich eben nicht codiere, und daraus ergeben sich oft komishce sachen und vermutungen... ich steh dazu auch...aber nicht, wenn man mich dämlich anmacht. :-D

aber das ist OT... wo wir dann vermutlich zum xten mal in dieser woche sind, und vermutlich immer wieder kommen werden...wie alle hier.

wir sind doch hier im OT-Forum. Hier kanns also gar nicht mehr OT werden ;-)

Schade, daß sich meien Argumente nach Vermutungen anhörten, das waren sie nämlich nicht. Wie gesagt hab ich das mit dem SourceExchange aus dem Log gelesen. Wenn man dieses eine Weile genauer beobachtet, genau wie das emule-Verhalten insgesamt, kann man doch einige Rückschlüsse ziehen.

Ich komm übrigens auch noch aus der Zeit als man sich noch per Modem in die klassische Mailbox einwählte. Damals lernte ich auch die Intel-Pc-Welt kennen. Inzwischen kann ich glaub ich behaupten verfüg ich über reichlich gefährliches Halbwissen :mrgreen:

also hier nochmal werte:

Programm-Laufzeit: 14:21 Stunden
Dauer auf aktuellem Server: 14:21 Stunden (99,9%)

Uploads
Session
Hochgeladen: 1,44 GB
Totaler Overhead (Pakete): 36,64 MB (906K)
Overhead durch Dateianfragen (Pakete): 11,48 MB (599K)
Overhead durch Quellenaustausch (Pakete): 5,38 MB (6K)
Overhead durch Server (Pakete): 71 KB (4K)

Downloads
Session
Heruntergeladen: 1,15 GB
Totaler Overhead (Pakete): 32,87 MB (849K)
Overhead durch Dateianfragen (Pakete): 13,42 MB (572K)
Overhead durch Quellenaustausch (Pakete): 5,19 MB (7K)
Overhead durch Server (Pakete): 94 KB (847)

nun sollte alles vollzählig vorhanden sein

Xman hat in seinem Post einen Fakt vermittelt, den er aus einem Logfile hat, er hat ihn in zwei Zeilen für mich nachvollziehbar dargestellt. Natürlich könnte es falsch sein, ich denke, in folgenden Fällen:

1. Die Logausgabe ist falsch. Halte ich für extrem unwahrscheinlich.

2. Xman lügt. Auch extrem unwahrscheinlich, weil man es zum einen selber prüfen kann, zum anderen, warum sollte er?

Würde mich wirklich mal extrem interessieren, wie du diesen Fakt auf 10+ Zeilen ausbreitest, und zwar so, das der Rest nicht nur heiße Luft ist. Kannst ja mal ne PM schicken, wenn du willst.

Halloho, Erde an MxM., die Zeiten haben sich geändert. Es spricht nichts gegen inhaltlich gute, lange Beiträge. Andererseits ist nicht ein langer Beitrag automatisch besser als ein kürzer. Wenn ich einen kurzen und einen langen Beitrag habe, und beide vermitteln das gleichen, wieso sollte ich dann den langen lesen?



ich spiele jetzt mal mit den Werten von renegade rum, ohne diese als Zitat zu kennzeichnen, man möge mir verzeihen. Des weiteren mache ich die Umrechnung MB -> kB mit 1024, wie es ja normalerweise der Fall ist. Wenn in der Statistik mit 1000 gerechnet wird, hält sich der Fehler aber in Grenzen. Außerdem sind alle Werte zwangsweise nur Rundungswerte.

Uploads Session
Totaler Overhead (Pakete): 36,64 MB (906K) = 42 Byte/Paket
Overhead durch Dateianfragen (Pakete): 11,48 MB (599K) = 20 Byte/Paket
Overhead durch Quellenaustausch (Pakete): 5,38 MB (6K) = 940 Byte/Paket
Overhead durch Server (Pakete): 71 KB (4K) = 18 Byte/Paket

Downloads Session
Totaler Overhead (Pakete): 32,87 MB (849K) = 41 Byte/Paket
Overhead durch Dateianfragen (Pakete): 13,42 MB (572K) = 25 Byte/Paket
Overhead durch Quellenaustausch (Pakete): 5,19 MB (7K) = 777 Byte/Paket
Overhead durch Server (Pakete): 94 KB (847) = 114 Byte/Paket

Ok, soweit die reine Rechnerei, versuchen wir mal was daraus zu lesen:

Eine Dateianfrage im Upload/Download hat ungefähr 2x Byte. Eine Dateihash hat 16 Byte, der muß ja mindestens mit rein, damit der andere weiß, welche Datei ich suche bzw. selber habe. Der Rest geht wohl für Protokoll-Overhead drauf (ich meine jetzt das ed2k-Protokoll).

Der Quellenaustausch ist auch interessant, aber jetzt wird meine Überlegung schon wackelig, weil ich nicht genau weiß, was da reinzählt. Fakt ist, das die Pakete im Up- und Download halbwegs gleich sind (ja, sie sind unterschiedlich, aber nicht extrem). Meiner Meinung nach müßte es ein Mischwert aus den Paketen "Ich suche Quellen für Datei AB" und "Hier Liste mit Quellen für Datei AB" sein. Der erste Pakettyp müßte eigentlich genauso groß sein wie der für die Quellensuche, der zweite natürlich viel größer, da er eine Liste von Quellen enthält. Ich gehe jetzt mal davon aus, das sich die beiden Pakettypen die Waage halten (schon wieder eine wackelige Annahme), dann kann man ungefähr so rechnen:

Für den Upload:

Pakettyp 1 ("Gib Quellen für Ab"): 20 Bytes
(Typ 1 + Typ 2) / 2 = 940 Bytes
-> Pakettyp 2 = 1860 Bytes

Für den Download:

Pakettyp 1 ("Gib Quellen für Ab"): 25 Bytes
(Typ 1 + Typ 2) / 2 = 777 Bytes
-> Pakettyp 2 = 1529 Bytes


Man kommt ungefähr auf wieder genau ein Paket (14xx), da ich hier dauernd mit gerundeten Werten und wackeligen Annahmen rechne, liegt man halt ein Stück daneben.

Ich weiß, dieses Gedankenkonstrukt kann man in der Luft zerreißen, bitte nicht überbewerten, wollte nur mal ein paar Gedankengänge niederschreiben, die sogar meinen Erwartungen entsprochen haben. Wenn jemand der Meinung ist, ich habe Mist gerechnet, hat er wahrscheinlich sogar Recht ;-)

Auf jeden Fall sieht man, das der Serveroverhead überraschend gering ist. Und nicht vergessen: Wenn die Statistik nicht stimmt oder ich sie falsch interpretiert habe, ist eh alles umsonst ;-)

formulierung schwarz-weiss war eine allgemeine, keine speziell an xman gerichtete. ich wollte dadurch lediglich die schwierigkeit vermitteln, mit der man rechnen muss... wenn man über solche dinge kommuniziert. das ist nicht unbedingt gewollt, aber fazit diverser unterhaltungen.


der beitrag mit den langen texten hiess im umkehrschluß übrigens nicht, dass ein kurzer beitrag schlechter als ein langer ist. eigentlich war er nur ein stückweit rechtfertigung für längere beiträge mit einem kleinen vorwurf, dass ich das gefühl habe, manche sachen werden nicht ordentlich gelesen. als beispiel fällt mir odinasgardson mit der ersten ot-geschichte im wombat-thread ein.


bezüglich der upload und downloadwerte.... verstehe ich nicht ganz wie du bei einem von dir berechneten paket von 18xx auf einen 1492er wert kommst.... zumal, und das sollte man dazusagen... gerade wenn die MTU anders eingestellt ist, der wert mit noch höherer wahrscheinlichkeit fragmentiert wird. wenn also z.B. propagierte tools zum automatischen einstellen der MTU einen niedrigeren Wert festlegen, oder Windows das serlbst macht (ich vertraue dieser Sache ebensowenig wie Xman) dann wird gerade bei deinem berechneten wert von 18xx es immer unwahrscheinlicher dass er im bereich eines einzelnen paketes liegt.


darkwolf hatte im wombat thread erklärt, dass nach einem fragmentierten paket, ein paket mit der länge 0 kommt.

bei beiden von dir berechneten bytegrößen (beide über 14xx) komme ich damit ohne NOREFRAG option also auf 4 Pakete

Paket fragmented
0 size
Paket fragmented
0 size

so gelesen im wombat thread. ich schaue jetzt aber gleich nochmal rein in den thread.

bei dieser berechnung jedenfalls kommt auch ein upload und download ordentlich durcheinander... ist das ja schlussendlich auch gerade mal auf einen einzigen quellenaustausch...bzw. eigentlich sogar nur in eine richtung jeweils...also nichtmal AUSTAUSCH.

bei hin und zurück, kommen wir bei einem austausch also sogar auf insgesamt 8 pakete. aber ich schau wie gesagt gleich nochmal nach dem no refrag posting von darkwolf

ok

hab mich leicht geirrt... kommen bei dieser sache aber immernoch 4 Pakete zusammen, nur dass das dann mit no refrag von 4... auf sagen wir mal 3 Pakete runtergerechnet werden kann. was einer optimierung beim XS von satten 25 % je nach XS größe entspricht.


interessant wird die sache, was passiert, wenn ich einer einzelnen datei ca 1000 quellen erlaube... diese auch zustandekommen... dann sind wir mit den quellen allein IP = 4 bytes bei 4000 bytes, richtig ?

Nochmal was zur MTU Discovery:
Ich glaube darkwolf hat sich an dieser Stelle eh sehr unglücklich ausgedrückt. Es wird nämlich NICHT die MTU auf einen "korrekten" Wert angepaßt wie man es sich nun eigentlich vorstellt. Anders gesagt: Die Option MTU Discovery (genauer gesagt MTU Path Discovery) ersetzt nicht das Konfigurieren der optimalen MTU.
Mit gesetzter MTU Path Discovery passiert nämlich folgendes...
Wenn sich 2 Clients treffen (müssen keine emule-clients sein, kann auch server + Browser sein), so tauschen sie sich aus, welche MTU die größte auf ihrer Verbindungsstrecke ist, welche nicht fragmentiert werden muß.
Hier noch der Schwarz-Weiß-Text ;-)
original Text der RFC. Link: http://www.faqs.org/rfcs/rfc1191.html

Warum ich diese Option seit ich emule benutze ausgeschaltet hab ist leicht erklärt. Für EINE Verbdingung (Client - Server) mag es Sinn machen, da hiermit die Downloadrate optimiert werden kann. Für viele Verbindungen (emule) ist damit ein zusätzlicher Zeitaufwand verbunden. Rein subjektiv betrachtet hat sich das Verbinden zu den Clients durch emule verbessert. Objektiv betrachtet kann man dazu rein gar nichts sagen. Dazu müßte man schon wirklich jedes Byte das auf dem Netzwerk liegt, samt Geschwindigkeit genaustens Analysieren. Die Geräte dies hierfür gibt sind sündhaft teuer und zusätzlich bräuchte es eh noch den Sachverstand eines wirklichen Profis.

mfG
Xman - diesmal kein Zweizeiler ;-)


//Edit:
Ich sollte es nochmal klarer zum Ausdruck bringen, warum MTU Path discovery nicht das Einstellen einer optimalen MTU ersetzt.
Hat ein anderer Client eh ne kleine MTU (Modem, 512 oder sowas wars), so wird eh diese MTU verwendet. Nochmal zur Erinnerung MTU = MAX Transfer Unit.
Weiß ich, daß mein Provider max 1436 ohne Fragmentierung läuft, brauch ich den Wert nicht höher zu setzen, eh es dann mit MTU discovery dann eh wieder runtergesetzt wird.

MxM.,

ich weiß nicht, warum du so auf dem 18xx rumreitest, wie ich mehr als deutlich geschrieben habe, beruht der Wert auf Berechnungen mit anderen Werten, die MEHRFACH gerundet sind, der Berechnungsfehler ist also extrem. Ich wollte eigentlich nur zeigen, das die Werte in einer Größenordnung liegen (18xx ist die gleiche Größenordnung wie 14xx, 18xxx wäre eine andere Größenordnung). Das ich mich mit meiner Rechnung extrem aus dem Fenster lehne, war mir bewußt, das du das natürlich als Aufhänger nimmst, auch. Die Werte sind extrem ungenau, wir wissen nicht, in welche Richtung sie tendieren, wenn sie genauer wären. Da darkwolf eh geschrieben hat, das man mit der MTU so gut wie nichts verbessern kann, ist die Diskussion eh so gut wie erledigt. Im nächsten eWombat ist dann die MTU einstellbar, da kann dann jeder nach herzenslust optimieren, und wenn dann jemand damit nachvollziehbare Verbesserungen erziehlt, soll er die Werte posten. Bis dahin werde ich mich mit weiterer Diskussion zurückhalten.

18xx ist einfach 20% mehr als 15xx.

ich denke übrigens, wenn es eine norefrag option gibt ist das ganze wesentlich sinnvoller, als wenn ich die MTU verstelle. da der MTU für jede Datei anders sein wird, wird wie richtig gesagt damit nicht soviel verändert werden...

vor der diskussion wußte ich nur nicht, dass es eine interne MTU gibt... was ich ursprünglich zu bemängeln hatte bezog sich auf die windows interne MTU ...und da auch nur auf eine fest, aber falsch eingestellte.

da sowohl eine 18xx als auch eine 15xx gesplittet werden müssen und beide in 2 teile getrennt werden...macht hier nicht der MTU wert als festes den salat aus, sondern wenn dann tatsächlich das norefrag, welches den leeren teil cuttet. was ich sehr sinnvoll finde.

an der stelle gehts an die form von verschwendung, wegen derer ich das ganze angesprochen habe. verschwendung durch fehlnutzung der MTU größe.

MxM.,
daß es 2 verschiedene MTUs gibt, war für mich auch das wichtigste was ich aus darkwolfs Aussagen gelesen hab. Mit einem Schlag gingen mir die Augen auf, warum man auf emule-project.net so unterschiedliche Aussagen zur MTU liest. Nun weiß ich, daß ich zwischen windows und emule MTU differenzieren muß.

MxM.,

Och manne, muß man immer alles so genau erklären. Ich habe geschrieben, das ich mit extrem schlechten Werten gerechnet habe, es könnte gut sein, das die Berechnungsfehler so groß sind, das aus der 18xx eigentlich eine 12xx wird. Natürlich kann dann genausogut eine 24xx bei rauskommen, ist mir auch klar. Wenn ich aber durch Rechnung mit ungenauen Werten auf eine 18xxx (also eine Größenordnung mehr) gekommen WÄRE, dann hätten die Meßfehler es auch nichts mehr rausgerissen, damit wäre man nie bei genauer Messung auf 12xx gekommen. Ich wollte nur zeigen, das die Möglichkeit besteht, nicht das es so ist. Können wir die 18xx jetzt mal ruhen lassen? Ich bereue es schon wieder, mal etwas in der Luft rumgerechnet zu haben. Du hättest vermutlich auch rumgemeckert, wenn ich um 5% daneben gelegen hätte. Ich habe mehr als deutlich genug gesagt, das man die Rechnung nicht so genau nehmen darf wegen der Häufung von Rundungen und Meßfehlern, und du hackst auf 20% rum.

Schön, das du endlich mal in KURZER Form PRÄZISE formulierst, worum es dir von Anfang an ging ;-)

Letztenendes ist es wohl ein Problem der Netzwerkschichten. Jede Applikation hat wohl die Wahl, auf welcher Schicht des Netzwerks es arbeitet, bei einem Browser wird der Programmiere wohl nur zu Windows sagen, schick mal die Daten dahin, sowas wie eine MTU-Einstellung ist mir bei keinem Browser bekannt, die richtige MTU bestimmt in dem Fall Windows. Wenn ich einen Firewall oder einen Sniffer programmiere, muß ich die Pakete in einer viel tieferen Schicht abfassen, um die gesamte Kontrolle zu haben und um effizient zu sein. Emule liegt wohl irgendwo dazwischen, baut TCP/UDP-Pakete zusammen und gibt sie an die darunterliegende Schicht ab, die Verantwortung der MTU liegt bei Emule selbst, aber Emule wird nicht so tief ansetzen wie z.B. eine Firewall, aber wohl tiefer als ein Browser. So wie es wohl raus gekommen ist, ignoriert Emule wohl die Einstellungen der MTU in Windows (oder halt den ermittelten Wert von Windows). Daraus folgt ja wohl auch, das ein manuelles ändern der MTU in der Registry für Emule keine Bedeutung hat.

Ihr seid alle sehr lustig.
Alles durchgelesen und nur Bahnhof.
Was kann ich den nun für einen Wert beim ikabot einstellen ?
Da schreibt hier keiner was von.
Der Standartwert ist 1340. Kann ich nun höher gehen oder so lasssen ?

Habe versuchshalber mal 1480 eingegeben und nach euren Aussagen
müsste das sich in der Statistik mit mehr fehlgeschlagenen DL´s / UL ´s
bemerkbar machen. Aber nach über 3 Std. hat sich nichts verändert.
Die fehlgeschlagenen DL´s habe sich sogar etwas verringert .3% bis .5%

Hilfe - macht mich schlau ! :wink:

blomy,
also nach meiner Aussage müßtest Du mit nicht mehr Fehlgeschlagenem Rechen.

Im übrigen sind einige Mod-Programmiererr dazu übergegangen die dort einstellbare MTU in MSS zu taufen. Zur Erinnerung: MTU= Maximum Tranfer Unit, MSS= Maximum Segment Size. MSS = die Nutzdaten pro Einheit und sind immer 40 Byte kleiner als MTU. 40 Byte sind nämlich der Header pro Packet.
MSS ist sehr viel günstiger von der Bezeichnung gewählt als MTU. Denn die Packete die der Esel schnürt sind grundsätzlich ohne Header (nur emule-Protokoll-header, die mit TCPIP aber nichts zu tun haben).
Der wohl optimalste MTU/MSS(je nachdem wie getauft) Wert des Esels ist dann meines Erachtens: optimale MTU des Providers bei der nicht fragmentiert wird -40.
Wäre smit bei vielen DSL-Verbidnungen also 1436 - 40 = 1396.
Ob man nun aber wirklich bessere Geschwindikeiten damit erzielt sei dahingestellt.