MTU maximum transfer unit

MxM. · 25. July 2003, 13:13

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

**Usul** · 25. July 2003, 14:00

Hier mal ne kleine Ergänzung von mir (kopiert von hier):

Zitat:

1.2 MTU = Maximum Transmission Unit

[4.2.1], [4.2.2], [4.2.3]

Die Maximum Transmission Unit (MTU) einer Netzwerk Schnittstelle (Interface) gibt das größtmögliche IP Datenpaket an, das ohne Fragmentierung (Aufsplittung in mehrere kleinere Pakete) über diese transportiert werden kann.

In Netzen auf Ethernet Basis (z.B. die meisten lokalen Netze) werden die IP Datenpakete in sogenannten "Ethernet Frames" transportiert. Die maximale Größe eines einzelnen Ethernet Frame Paketes ist 1518 Byte. Davon werden 14 Byte vom (Ethernet-) Header und 4 Byte von der Checksumme für das Frame beansprucht, sodass also noch genau 1500 Bytes an Nutzdaten (<-> IP Datenpaket) für ein solches Ethernet Frame übrigbleiben. Deshalb ist die Maximum Transmission Unit (MTU) einer Ethernet Schnittstelle (z.B. einer Netzwerkkarte im Rechner) 1500 Byte groß.

index
1.2.1 MTU bei PPPoE-Verbindungen

[4.2.1]

Eine Ethernet-Verbindung (wie u.a. PPPoE) hat laut Standard eine MTU von 1500 Byte. Hierbei sind allerdings noch nicht die 8 zusätzlichen Byte für das PPPoE-Protokoll berücksichtigt. Um also inklusive den PPPoE-Headern noch standardkonforme Ethernet-Pakete zu senden, darf die MTU für PPPoE-Verbindungen höchstens 1492 Byte groß sein (siehe RFC 2516).

Genaugenommen [4.4.2] sollte der MTU-Wert bei PPPoE genau 8 Byte weniger (der zusätzliche PPPoE Protokoll Header) als jedes Interface zwischen dem eigenen Rechner und dem Ziel sein. "Normalerweise" sollten alle Router im Internet auf eine MTU von 1500 konfiguriert sein [1.2], sodass 1492 korrekt sein sollte.Trotzdem kann es aber mal vorkommen, dass sich ein Router nicht daran hält. Abhilfe schafft hier nur ein ständiges Verringern des eigenen MTU-Wertes, bis es "funktioniert".

Jetzt noch ein paar Anmerkungen, wie sich die Änderung der MTU auf welche Werte in Emule niedergeschlagen hat, wäre nicht schlecht.

MxM. · 25. July 2003, 14:17

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

**Usul** · 25. July 2003, 15:15

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.

MxM. · 25. July 2003, 17:17

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

darkwolf

Zitat:

Hi,

@MxM, wenn dich die ganzen Protokollgeschichten so sehr interessieren, lies dir die
sachen auf emule-projekt durch u n d analysiere die Sourcecodes und zieh dir vieleicht mal ein paar Info's über TCPIP rein...(und das ist jetzt tatsächlich so gemeint wie es sich anhört)

zum MTU: Das hat erstmal nichts mit dem eMule zu tun. Das ist einfach die Packetgrösse von TCPIP (die ideale grösse hängt von eurem ISP ab, bei T-DSL ist es 1500).
Wird nun ein TCPIP-Packet verschickt, das grösser als die MTU ist, wird dieses Packet gesplittet was ein bisschen Netzwerk-Overhead zur folge hat.
Die eMule Client<=>Client Packete sind alle immer kleiner als die MTU, theoretisch bringt die einstellung nur etwas beim DL und UL. Aber erstmal muss man wissen welcher MTU bei Windows eingestellt ist und welche MTU der ISP verwendet.
Eine Anleitung wie man das macht findet ihr hier: http://www.tek-tips.com/gfaq.cfm/lev2/5/lev3/60/pid/581

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

**Usul** · 25. July 2003, 18:13

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

MxM. · 25. July 2003, 19:00

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

MxM. · 25. July 2003, 19:09

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

**Usul** · 25. July 2003, 19:52

Zitat:

Zitat von MxM.

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 ?!

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.

Zitat:

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

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.

Zitat:

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

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.

Zitat:

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

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?

MxM. · 25. July 2003, 19:58

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 ?

**cyrex2001** · 25. July 2003, 20:20

also hier mal aus den faq's:

Zitat:

Zitat von http://www.emule-project.net/faq/de_source.htm

Quellenaustausch zwischen Clients
(Client To Client Source Exchange)

eMule ist in der Lage, mit anderen eMule-Clients Quellen direkt auszutauschen.

Bei gut verbreiteten Dateien wird alle 10 Minuten ein zufällig ausgewählter Client aus den zur Verfügung stehenden Quellen nach weiteren Quellen gefragt. Ist eine Datei selten (weniger als 40 Quellen), so wird in diesem Intervall bei jedem Client nach seinen Quellen gefragt.

Nur die Quellen für noch fehlende Teile werden ausgetauscht. Dies geschieht mittels komprimierter Paketeüber TCP*, um Bandbreite zu sparen.

cyrex2001
ps:

Zitat:

Der Quellentausch erfolgt über den Client Port 4662 im Protokoll TCP.

**Usul** · 25. July 2003, 20:23

Zitat:

Zitat von MxM.

ich meine kann doch nicht unendlich netzwerkverbindungen geben, oder ?

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 9

. Gibt es Limits beim Modem, bei der Telekom oder wo?

**Usul** · 25. July 2003, 20:29

cyrex2001,

ja, das habe ich auch gelesen, allerdings steht an anderer Stelle

Zitat:

UDP Port
Über diesen Port sendet eMule die Informationen seines erweiterten Protokolls, wie z.B. den Quellenaustausch zwischen den Clients oder die Quellenanfrage bei kompatiblen eMule-Clients. Dadurch wird der so genannte Overhead reduziert und gleichzeitig auch die Server entlastet. Dieser Port muß ebenfalls in Eurer Router- oder Firewallkonfiguration freigegeben sein. Sollte dies nicht möglich sein, könnt Ihr die UDP-Funktion deaktivieren; eMule nutzt dann den konventionellen Weg der Anfragen etc. über die Server (dies wird allerdings nicht empfohlen).

Scheinbar wiederspricht sich die Dokumentation hier etwas.

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