Archiv verlassen und diese Seite im Standarddesign anzeigen : Probleme mit MTU-Wert
Hallo
Ich habe einen T-DSL 6000 Anschluß und in letzter Zeit Probleme mit unglaublichen Pingspitzen bei Spielen. Jetzt habe ich mal ein paar Tests durchgeführt und bin zu folgendem Ergebnis gekommen:
Am Router voreingestellt ist ein MTU von 1492.
Wenn ich jedoch ein Paket mit 1492 Byte (=1464+28) rauschicken will, dann klappt es nicht:
ping -f -l 1464 www.t-online.de
liefert bei mir:
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Nach einigen Proben zeigt sich, daß das größte Paket, welches bei mir rausgeht maximal 1486 Byte (= 1458+28) groß sein darf:
ping -f -l 1458 www.t-online.de
Meine Fragen:
1. Ich spiele mit dem Gedanken den MTU-Wert im Router auf 1486 abzusenken. Macht das Sinn? Die Leitung wird bei einem Router-Reset ja jedesmal neu ausgehandelt. Könnte es sein, daß die Leitung dann noch schlechter wird, wenn ich den MTU-Wert im voraus absenke?
2. Was muß ich tun, damit auch Windows XP mitbekommt, daß keine Pakete über 1486 rausgehen sollen? Den Traffic-Shaper cfos möchte ich nicht installieren. Dort ist mal wieder lauter Zeug eingebaut, das man nicht haben will (noch eine Firewall & jede Menge PopUps und ScareWare).
Hat jemand mal den TCP Optimizer von Speed Guide ausprobiert?
http://www.speedguide.net/downloads.php
3. Es ist mir bekannt, daß all diese Tools zusätzliche Registrierungseinträge vornehmen. Reicht es, wenn ich einen Systemwiederherstellungspunkt setze, um die Änderungen, die diese Tools verursachen vollständig rückgangig machen zu können?
4. Gibt es einen kostenlosen Traffic-Shaper, den man empfehlen kann? Bzw. ist so eine Funktion im kostenlosen T-DSL-Manager enthalten?
http://www.chip.de/downloads/T-DSL-Manager_12991450.html
Danke schonmal für's lesen.
Hallo,
da Onlinespiele UDP (und somit kein TCP) verwenden, hilft das rumdoktern am TCP nichts.
mfg
Ich glaub das verwechselst du. UDP ist nur ein abgespecktes (deswegen schnelleres) Zusatzprotokoll, welches allerdings einen TCP/IP Adapter voraussetzt. Alle Einstellungen, die man für TCP/IP vornimmt gelten deswegen auch für UDP.
Das Absenken des MTU-Wertes über den TCP-Optimizer hat mein Problem mit den Pingspitzen allerdings nicht lösen können.
Ich glaub das verwechselst du. UDP ist nur ein abgespecktes (deswegen schnelleres) Zusatzprotokoll, welches allerdings einen TCP/IP Adapter voraussetzt. Alle Einstellungen, die man für TCP/IP vornimmt gelten deswegen auch für UDP.
Das Absenken des MTU-Wertes über den TCP-Optimizer hat mein Problem mit den Pingspitzen allerdings nicht lösen können.
Hallo,
IP ist das Adressierungsprotokoll auf OSI Layer 3, TCP und UDP sind zwei verschiede Transportprotokolle auf OSI Layer 4. UDP ist ein einfacheres Protkoll aber nicht von TCP abhängig. Einstellungen von MSS, RWIN usw. gelten nicht für UDP, da UDP keine Verbindungen oder Fragmentierung unterstützt. Ein absenken der MTU verringert den Ping bei UDP (natürlich) nicht.
Schau doch mal mit Wireshark was auf der Leitung genau passiert.
mfg
Für mehr Infos zu UDP
http://www.faqs.org/rfcs/rfc768.html
zu TCP
http://www.faqs.org/rfcs/rfc793.html
Hallo,
IP ist das Adressierungsprotokoll auf OSI Layer 3, TCP und UDP sind zwei verschiede Transportprotokolle auf OSI Layer 4. UDP ist ein einfacheres Protkoll aber nicht von TCP abhängig. Einstellungen von MSS, RWIN usw. gelten nicht für UDP, da UDP keine Verbindungen oder Fragmentierung unterstützt. Ein absenken der MTU verringert den Ping bei UDP (natürlich) nicht.
Schau doch mal mit Wireshark was auf der Leitung genau passiert.
mfg
Für mehr Infos zu UDP
http://www.faqs.org/rfcs/rfc768.html
zu TCP
http://www.faqs.org/rfcs/rfc793.html
Ich habe inzwischen schon mehrere Tests laufen lassen. Das Problem ist, daß ich um den Fehler zu reproduzieren immer 5 Leute online brauche. - Wir sind aber inzwischen schon einen Schritt weiter. Es scheint kein Problem mit der Leitung selbst zu sein, sondern ein Programmierfehler in Windows XP bzw. Ventrilo. Die windowsinterne Bandbreitenverteilung funktioniert nicht bzw. schlecht und verursacht einen Paketstau. Anders kann ich mir das ganze kaum noch erklären.
Die Pingspitzen treten auf, sobald Ventrilo anfängt Datenpakete rauszuschicken (also wenn ich spreche). Wenn ich mit Pausen immer wieder etwas sage, bricht irgendwann die Leitung komplett zusammen (desync). Man könnte also auf die Idee kommen, daß irgendwas mit der Leitung nicht stimmt (zB. zu wenig Kapazität beim Upload etc.). Aber jetzt kommt das Mysteriöse: Wenn die Belastung der Leitung durch Ventrilo über mehrere Minuten konstant bleibt, baut sich die Verstopfung(?) beim Upload von selbst ab, und alles läuft wieder wie geschmiert. Ich kann reden solange ich will ohne desync, solange ich die ganze Zeit über den Push-To-Talk-Key gedrückt halte (also solange Ventrilo nicht von neuem einen Upload startet). Da steckt irgendwo ein Fehler im System. Ich weiß allerdings nicht, wo ich noch schrauben könnte, um da was zu ändern.
Es ist mir ein Rätsel. - Aber ich bin mit dem Problem nicht allein. Andere hatten das Problem auch schon (sogar Leute mit ADSL 16.000) nur bei denen ist es angeblich irgendwann von alleine wieder verschwunden. Tja - sehr merkwürdig. Wenn alle Stricke reißen, werden wir wohl wieder auf Teamspeak umsteigen. :( Irgendwo ist da ein Fehler, der möglicherweise nur wenig mit der Bandbreite selbst zu tun hat. Vielleicht liegts auch an meinem NAT-Router? Vielleicht kriegt der die Pakete nicht in eine ordentliche Reihenfolge.....
Ich werd noch ein bischen rumprobieren - und dann müssen wir uns wohl von Ventrilo verabschieden. ;(
Hallo,
der Tipp bleibt Wireshark, schau mal nach den CoS oder ToS werten (bits).
Das Problem wir dnicht Windows sein, eventl. reagiert dein Router etwas panisch auf den UDp Strom oder ebend die CoS/ToS Werte.
mfg
Hallo,
der Tipp bleibt Wireshark, schau mal nach den CoS oder ToS werten (bits).
Das Problem wir dnicht Windows sein, eventl. reagiert dein Router etwas panisch auf den UDp Strom oder ebend die CoS/ToS Werte.
mfg
Ich hab mir mal Wireshark installiert... zuerst war ich etwas skeptisch (ich halte normalerweise nichts von Programmen die ich nicht kenne und meinen Netzverkehr aufzeichnen) - aber da es der Nachfolger von ethereal ist, scheint es wohl ok zu sein (das hatte ich früher schonmal im Einsatz, als es Schwierigkeiten unter W98 und ICS gab).
Ich bin schonmal auf den ersten Capture gespannt. - Es müssen nur alle Leute mal wieder gleichzeitig online sein... das einzige Problem, daß ich bei Wireshark noch sehe ist, daß ich möglicherweise das Problem nicht erkenne, selbst wenn ich es Dank Wireshark sehe. ;)
Don-Roland
2009-10-22, 06:06:36
@ Gast
Falls du Vista hast, mußt du nichts an den Internet Einstellungen optimieren, weil das Vista automatisch macht.
@ Gast
Falls du Vista hast, mußt du nichts an den Internet Einstellungen optimieren, weil das Vista automatisch macht.
Was für eine Horrorvision! ;)
Ne - ich hab XP. Und mittlerweile hat es sich herausgestellt, daß es weder Bandbreitenprobleme (zuwenig Upload) noch falsch konfigurierte Hardware ist. Es handelt sich mit sehr hoher Wahrscheinlichkeit um nicht-optimierten Netzcode:
SupComFA(MultiplayerLAN) & Ventrilo <-> hamachi <-> NAT-Router => mit DSL 2000 ab Kartengröße 10 und 4 Spieler nicht spielbar (wenn man F11 drückt sieht man Pingspitzen, die irgendwann zum desync führen).
SupComFA(GPGNET) & Ventrilo(hamachi) <-> NAT-Router => mit DSL 2000 bis jetzt keine Probleme mehr. Der Ping ist sogar um fast 30% besser geworden, als wenn die SupCom-Pakete ebenfalls über hamachi-VPN getunnnelt werden. :uponder: Möglicherweise auch ein hamachi Problem.
Demnächst werden wir es nochmal mit 5 Spielern testen. Aber ich bin zuversichtlich, daß das Problem 'gelöst' ist. Möglicherweise hat man sich beim Netzcode von SupCom bei Spielen über LAN sich nicht soviel um eine Optimierung bemüht. Oder hamachi macht Fehler beim Tunneln von 2 Anwendungen mit gleicher Priorität.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.