TCP Window size

[jomaster]

Hallo zusammen,

nachdem die Performance bei einem unserer Firmennetzwerke ziemlich mies ist, haben wir beschlossen den alten HP Switch rauszubauen und gegen einen neueren zu tauschen. Jetzt habe ich vorher noch einen Test angefertigt um einen Vorher Nachher vergleich zu haben und dabei festgestellt, dass die TCP Window Size in diesem Netzwerk gerademal bei 8KByte ist. Mit iPerf mehrfach getestet, er geht immer runter auf 8k Byte. An was kann das liegen?

Zudem noch die Frage iniwefern sich das auf die Performance auswirkt? Bei einem großen Stream einer Datei kommen schlechte Transferrraten zustande, bei vielen parallel, scheint er vollen Durchsatz zu haben. Sollte es nicht umgedreht sein, oder habe ich da einen Denkfehler?

 

[3rdStar]

Was war das für ein Switch?
Wieviele Clients?
Homogenes System?

uswusf... mit so wenig Information kommt man meist nicht weit...

 

[conf_t]

Die TCP Window Size wird vom jeweiligen Betriebssystem der Servers und des Clients verwaltet. Aber Hauptsache mal die Switche raushauen. Die meisten Modelle die 10 Jahre alt sind wuppen den Office Bedarf heute noch.
Es kommt immer darauf an, ob Sender oder Empfänger eine kleine Window Size haben. Beim Sender ist das erst Mal vernachlässigbar. Beim Empfänger kann das zum Problem werden.
Die Window Size ist der Empfangspuffer und zeigt an wie viele Bytes vor der Verarbeitung durch die Software gepuffert werden können. Sprich TCP Window Size geteilt durch Paketgröße ergibt die Anzahl der Pakete die quasi-simultan versendet werden kann. Die Auswirkung auf die Performance ist massiv.
Switche haben damit nix zu tun.

 

[Lawnmower]

Also gemäss Wikipedia wird die TCP WindowSize in modernen Betriebssystemen automatisch eingestellt: https://de.wikipedia.org/wiki/TCP_Receive_Window
Bei iperf ist 8 KB Standard für TCP, Du musst es per Parameter anpassen wenn Du es anders haben willst.

 

[d2boxSteve]

Les dich da mal ein: https://de.wikipedia.org/wiki/Jumbo_Frames

 

[cbtestarossa]

Keine Ahnung wie sich das auswirkt,
Schau auch mal auf Wikipedia bei Jumbo Frames und MTU

Wobei dann glaub alle Geräte selbe Framegrösse haben sollten.
Und ein Router ins Internet muss die dann eventuell wieder verkleinern da dort meist Größen von 1500 oder noch kleiner verwendet werden.

 

[conf_t]

An über mir: TCP Window Size hat mal so gar nichts mit der Framegröße (MTU/Jumboframe) zu tun.
Wer mehr dazu wissen will, dem empfehle ich die Sharkfest Videos auf YouTube (english).

Wie der TE bemerkt hat läuft eine Anwendung mit zu kleiner Window Size sauber ins Protokolllimit/Softwarelimit. Da helfen auch keine Zigtrillionen Megabit oder neue Switche oder Router.

Statt das Geld mit neuen Switch zu verpulvern besser mal einen fähigen Paketanalyst anheuern.

 

[3rdStar]

spezialisiere mal die Bedingungen hinter deiner Frage...

 

[jomaster]

Bin schon dabei ...

Am einen Ende hängt auf einem Cisco Sg200-26 die Serverstruktur des CAD-Netz, laufen insgesamt 16 Server, die gehen über eine 1G Kupfer Verbindung auf einen HP V1810-48G. Dort hängen das andere Ende mit 46 Clients und Drucker dran und einen weiteren Uplink zu einem Cisco SG350X-52 auf dem nochmal 16 Clients und Drucker hängen.
Ich kann zwar keine Netzwerkprobleme ermessen, da mir das Hintergrund wissen dafür fehlt, aber mein Bauchgefühl sagt mir, die 1G Kupferverbindung zu den Servern ist schlecht.

iPerf hat mir bei allen anderen Clients\Netzen automatisch mit 64kByte TCP gestartet und gearbeitet. Nur in diesem CAD Netzbereich mit 8. Daher meine Vermutung, dass es nur in diesem Segment ist. Und die Switche werden wegen diesem gefühlten Botteleneck von 1G getauscht, nicht weil das TCP Window zu klein ist. Das ist mir nur aufgefallen als eine der weiteren möglichen Ursachen für Performance Schwäche.

 

[cbtestarossa]

@conf_t
RWIN wird sowieso automatisch verwaltet.
Klar kann man die auch manuell einstellen. Ich würde da aber nicht herumbasteln.

 

[conf_t]

Jein.
Ja es wird automatisch verwaltet und man sollte daran auch nicht besser rumspielen, aber viele Lastverteiler können/dürfen zwar TCP-Window-Scale, aber nur bis 64k, was wieder dem regulären max TCP Window entspräche. Was also so gut ist wie gar kein Windows-Scale.
Ebenso müssen Server und Client TCP-Window-Scale unterstützen und da ist ggf. Handanlegen gefragt.
Bei Laufzeiten < 1 ms ist Window Scale noch nicht so relevant aber mit zunehmender Laufzeit.
Hier ein tolles Spielzeug um verschiedene Limitierung theoretisch zu berechnen.
https://wand.net.nz/~perry/max_download.php

Letztlich ist TCP eine logische Punkt zu Punkt Verbindung Probleme bei TCP den TCP Optionen/Eigenschaften sind an den Layer4 - Endpunkten (was ein Server, eine Lastverteiler/Firewall/Packet-Inspection oder der Client sein kann) zu suchen und nicht am Layer2 Switch oder Router - was der TE zu glauben scheint.
Klar bei Delays oder Retransmission/Dup-Acks/Lost Segments usw. muss man sich die Geräte der Schichten darunter auch anschauen.

 

[3rdStar]

Wie sieht es mit LACP aus? Ich habe hier (als das Netz nicht mehr performant genug war), 4er Trunks zwischen den Switchen aufgebaut. Die Server sind jeweils mit 2er Trunks angeschlossen.

Hat 3 Jahre gereicht.

Mittlerweile ist das Datenaufkommen hier so groß geworden, dass ich die alten Switche entfernt habe.
Hier war als Coreswitch allerdings noch ein HP 4208 von 2004 am werkeln (kein Jumbo, Layer 2) aus dem ein HP 5406 wurde und die Etagenswitche HP 2510 wurden durch HP 2920 ersetzt.

Hier wartet jetzt keiner mehr auf seine Daten.