MTU maximum transfer unit

[Xman]

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

When one IP host has a large amount of data to send to another host,
the data is transmitted as a series of IP datagrams. It is usually
preferable that these datagrams be of the largest size that does not
require fragmentation anywhere along the path from the source to the
destination. This datagram size is referred to as the Path MTU (PMTU), and it is equal to the minimum of the MTUs of each hop in the path.
A shortcoming of the current Internet protocol suite is the lack of a standard mechanism for a host to discover the PMTU of an arbitrary path.

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.

[Usul]

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.

[MxM.]

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.

[Xman]

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ß.

[Usul]

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.

Zitat von MxM.

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

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.

[Blomy]

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 !

[Xman]

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.