:huh: Ich habe neben W2k div. Linux-Distributionen getestet. Dabei ist mir im Vergleich zu W2k aufgefallen, dass die LAN-Parameter bei Linux hinsichtlich RWIN, TTL und Timestamps abweichen. Die letzten beiden konnte ich in den config-Files
/proc/sys/net/ipv4/... anpassen.
Der RWIN bleibt hartnäckig bei Linux = 5840.
Ein Eintrag in den Config-Dateien tcp_rmem, tcp_wmem bringen nichts. Ich denke, gegenüber dem Win-Default 65536 ist der Wert zu klein.
Bei Downloads ist zumindest Linux langsamer.
Gleiche Hardware, den DSL-Router habe ich auf MTU/MSS 1492/1452 eingestellt (Tecom/T-Online).
Hat jemand einen Tip, wo ich konkret den RWIN dauerhaft anpassen kann ???
Die Test habe ich mit speedguide.net durchgeführt.
Gruß Muckl
Netzwerk optimieren
Hmm, von diesen "geheimen Windows-Registrytricks" halte ich sowieso nicht soviel. Meiner Meinung ist TCP/IP doch darauf ausgelegt immer den höchstmöglichen Datendurchsatz zu erreichen, indem es ständig versucht die Fenstergröße anzuheben.
Ist denn der Download eines Kernels von http://www.kernel.org wirklich langsamer unter Linux bei Dir als unter Windows? Oder versuche mal andere Quellen.... Ich surfe mit den Standardeinstellungen und bekomme eigentlich auch immer vollen QSC-Speed bei schnellen FTP-Servern.
Ist denn der Download eines Kernels von http://www.kernel.org wirklich langsamer unter Linux bei Dir als unter Windows? Oder versuche mal andere Quellen.... Ich surfe mit den Standardeinstellungen und bekomme eigentlich auch immer vollen QSC-Speed bei schnellen FTP-Servern.
Debian Sid
Kernel 2.6.9 swsusp2.1
KDE 3.3.1
Kernel 2.6.9 swsusp2.1
KDE 3.3.1
tcp_rmem bietet drei Werte. Hier ist deren Bedeutung.
Was für Werte stehen bei Dir da genau drin? Bei mir:
"4096 87380 174760"
Tip: Lese Deinen tatsächlichen Window-Wert aus laufenden Verbindungen ab (z.B. ethereal oder tcpdump). Und zwar aus den Paketen, die von Deiner Kiste ins Internet laufen (TCP Ack-Pakete).
Denn ein Vergleich mit speedguide.net zeigte bei mir, dass speedguide nicht das tatsächlich laufende receive-window beachtet, sondern nur den default-wert. Und das nützt Dir wenig, wenn Du wirklich wissen willst, was auf dem Draht abgeht.
Der tatsächlich laufende Window-Wert hängt bei weitem nicht nur von den defaults ab, sondern von den aktuellen RTT-Werten jeder einzelnen TCP-Verbindung.
Die Tips unter speedguide.net sind zum Teil fatal: wenn Du das TCP-Timestamping abschaltest, erhält der Kernel keine zuverlässigen Informationen, wie sich derzeit die RTT auf der Verbindung verhält. Und damit kann er nicht rechtzeitig auf Verstopfungen reagieren, sondern müllt das Netz unnötig zu. Wenn alle sich so verhalten, können kurzzeitige Engpässe zu Lawinen auflaufen.
Ausserdem ist der speedguide.net-server in Amerika. Die RTTs dort rüber sind schlecht, also geht auch Dein laufendes TCP-Window runter. Wie mein Messtechnik-Professor immer sagte: "Wer misst, misst Mist."
Was für Werte stehen bei Dir da genau drin? Bei mir:
"4096 87380 174760"
Tip: Lese Deinen tatsächlichen Window-Wert aus laufenden Verbindungen ab (z.B. ethereal oder tcpdump). Und zwar aus den Paketen, die von Deiner Kiste ins Internet laufen (TCP Ack-Pakete).
Denn ein Vergleich mit speedguide.net zeigte bei mir, dass speedguide nicht das tatsächlich laufende receive-window beachtet, sondern nur den default-wert. Und das nützt Dir wenig, wenn Du wirklich wissen willst, was auf dem Draht abgeht.
Der tatsächlich laufende Window-Wert hängt bei weitem nicht nur von den defaults ab, sondern von den aktuellen RTT-Werten jeder einzelnen TCP-Verbindung.
Die Tips unter speedguide.net sind zum Teil fatal: wenn Du das TCP-Timestamping abschaltest, erhält der Kernel keine zuverlässigen Informationen, wie sich derzeit die RTT auf der Verbindung verhält. Und damit kann er nicht rechtzeitig auf Verstopfungen reagieren, sondern müllt das Netz unnötig zu. Wenn alle sich so verhalten, können kurzzeitige Engpässe zu Lawinen auflaufen.
Ausserdem ist der speedguide.net-server in Amerika. Die RTTs dort rüber sind schlecht, also geht auch Dein laufendes TCP-Window runter. Wie mein Messtechnik-Professor immer sagte: "Wer misst, misst Mist."
TCP-Tuning ...
Hallo Huebi und basman,
sorry das ich erst heute wieder reagiere.
Also ich habe etliches getestet, vielleicht ist mein Vorgehen nicht gerade professionell...
Nun im Web steht an einigen versteckten Stellen auch mal was zum Ausdrucken diesbezüglich, aber die Selektion Gut/Schlecht ist nicht immer einfach.
Folgendes Ergebnis : Wenn die Timestamps defaultmäßig "on" deaktiviert werden, ist der effektive Download im Schnitt 10 k besser (bei mir te-com/T-online 2000). Jedoch wird beim Surfen es hin und wieder rucklig oder eine Seite kann nicht angezeigt werden.
Die RWIN-Werte bei speedguide.net sind tatsächlich nur statisch ermittelt - mir scheint so, dass bei Windows ein Wert 65535 hinterlegt ist, jedoch bei Linux der Wertebereich min - default - max
wirkt jedoch statisch 5840 angezeigt wird. Der Dateieintrag bei mir lautet 4096 - 87380 4194304. Praktisch habe ich durch Wertänderung keine praktische Veränderung festgestellt.
Sicher kann ein TCP'Freak aus den Paketen mehr erkennen - und mit entsprechendem Meßequipment in einem LAN-Netz ohne äußere Interneteinflüsse.
Zumindest stimmen die Downloadwerte bei Win2000 und Linux jetzt überein wenn die Timestamps entweder aktiv oder inaktiv sind.
Sicher ist der Parameter angeschaltet sinnvoller, ich habe das bei W2k mit "Dr. TCP" verändert.
Insgesamt muß ich sagen, dass ich eine Menge Zeit damit verbracht habe und im Ergebnis jetzt die Parameter etwas klarer sind, jedoch ein Tuning bei Normal-DSl nicht lohnt.
Interessieren würde mich noch, wenn schon Timestamps an den Paketen hängen und aktiviert sind, ob dieses lohnt (evtl. bei Video-Real-Streams Online-TV etc. eine vernünftigere Paketfolge zu erreichen, sofern
Zwischenspeicher schon gefüllt sind)
Muckl
sorry das ich erst heute wieder reagiere.
Also ich habe etliches getestet, vielleicht ist mein Vorgehen nicht gerade professionell...
Nun im Web steht an einigen versteckten Stellen auch mal was zum Ausdrucken diesbezüglich, aber die Selektion Gut/Schlecht ist nicht immer einfach.
Folgendes Ergebnis : Wenn die Timestamps defaultmäßig "on" deaktiviert werden, ist der effektive Download im Schnitt 10 k besser (bei mir te-com/T-online 2000). Jedoch wird beim Surfen es hin und wieder rucklig oder eine Seite kann nicht angezeigt werden.
Die RWIN-Werte bei speedguide.net sind tatsächlich nur statisch ermittelt - mir scheint so, dass bei Windows ein Wert 65535 hinterlegt ist, jedoch bei Linux der Wertebereich min - default - max
wirkt jedoch statisch 5840 angezeigt wird. Der Dateieintrag bei mir lautet 4096 - 87380 4194304. Praktisch habe ich durch Wertänderung keine praktische Veränderung festgestellt.
Sicher kann ein TCP'Freak aus den Paketen mehr erkennen - und mit entsprechendem Meßequipment in einem LAN-Netz ohne äußere Interneteinflüsse.
Zumindest stimmen die Downloadwerte bei Win2000 und Linux jetzt überein wenn die Timestamps entweder aktiv oder inaktiv sind.
Sicher ist der Parameter angeschaltet sinnvoller, ich habe das bei W2k mit "Dr. TCP" verändert.
Insgesamt muß ich sagen, dass ich eine Menge Zeit damit verbracht habe und im Ergebnis jetzt die Parameter etwas klarer sind, jedoch ein Tuning bei Normal-DSl nicht lohnt.
Interessieren würde mich noch, wenn schon Timestamps an den Paketen hängen und aktiviert sind, ob dieses lohnt (evtl. bei Video-Real-Streams Online-TV etc. eine vernünftigere Paketfolge zu erreichen, sofern
Zwischenspeicher schon gefüllt sind)
Muckl
-
pdreker
- Beiträge: 8298
- Registriert: 29.07.2002 21:53:30
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Nürnberg
TCP Pakete sind bereits durch ihre IPID und Sequence Number in der Reihenfolge eindeutig festgelegt, dazu braucht man die Timecodes nicht. Die Timecodes sind normalerweise nur dazu da den RTT Estimator zu füttern, der von Linux dann wiederum für das Window Scaling verwendet wird.
Patrick
Patrick
Definitely not a bot...
Jabber: pdreker@debianforum.de
Jabber: pdreker@debianforum.de