Viele retransmits

[b0nzai]

Hallo,

folgendes Problem:

In unserer Netwerkumgebung haben die mit Windows XP ausgestatteten Rechner sehr viele Retransmits (getestet mit netstat). Pro 100MB die auf unseren Fileserver geschoben werden immer 73.000 retransmits.

Die Rechner die noch unter Windows 2000 laufen (gleiche Hardware und Treiberversionen) haben dieses Problem nicht.

Habe nun eine XP Kiste frisch per Hand installiert. Auf dem Rechner ist also Windows XP und der Netzwerkkartentreiber. Auch dort habe ich pro 100MB 73.000 retransmits.

Nach einer Google suche bin ich auf das tool DrTCP gestoßen. Habe dort die Werte Window Scaling auf „Yes“ und Time Stamping auf „Yes“ gesetzt. Und tadaa: Keine retransmits.

Das ganze lässt sich dort auch reprodozieren: Stelle ich die Wert wieder auf „No“ habe ich wieder retransmits.

Auf allen anderen XP maschienen (inklusive dem neuinstallierten) hat das ganze nicht funktioniert.

Den gleichen Effekt gibt es im Übigen auch wenn ich versuche von einem XP Rechner auf einen 2000 oder einem anderen XP Rechner ein File zu verschieben.

Hat jemand eine Idee?

Schonmal danke in vorraus.

[Crash2001]

Die Window Size gibt an, wie viele Pakete übertragen werden können, bevor eine bestätigung beim Se4nder ankommen muss, dass die Pakete angekommen sind.

Aktiviert man die Möglichkeit, dass die Window Size bei Bedarf automatisch erhöht werden kann (bei grossen zu übertragenden Dateien z.B. sinnvoll), so kann die Datenübertragungsgeschwindigkeit zunehmen, falls vorher immer auf Empfangsbestätigungen gewartet werden musste. Kommt eine Weile keine Bestätigung für ein Paket, so wird es erneut übertragen. (bei TCP/IP - bei UDP/IP erfolgt keine bestätigung, ob ein Paket ankommt und daher wird auch kein Paket retransmittet).

Du könntest die Window Size auch in der Registry (oder in den Netzwerktreibern, falls dort verfügbar) manuell hochschrauben. Das sollte die Retransmits minimieren. Wird die Window Size jedoch zu hoch eingestellt, so müssen, falls auch nur eines der Paket nicht übertragen wird, die kompletten Pakete die in dieses Fenster fallen, neu übertragen werden.

[hades]

Windows hat bis XP bzw. 2003 generell eine zu kleine RWIN-Groesse fuer hoehere Bandbreiten. Die Standardeinstellungen basieren auf DFUe-Verbindungen ueber analoge Modems.

Die RWIN-Groesse wird normalerweise auf diesem Weg berechnet.

Maximum Segment Size (MSS) = MTU - 40

RWIN = MSS x 44

Das ist der max. moegliche Wert ohne TCP Window Scaling.

Im 100 Mbit/s-LAN hast Du normalerweise eine MTU von 1500.

Im Gigabit-LAN sind es ohne Einsatz von JumboFrames auch 1500 Byte.

D.h. ohne TCP Window Scaling hast Du nach der obigen Formel bei einer MTU 1500 max. 64240 Byte im RWIN zur Verfuegung.

Zustaendige Windows-Registry-Keys:

Pfad: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Schluessel: TcpWindowSize

Typ: DWORD

Schluessel: GlobalMaxTcpWindowSize

Typ: DWORD

Mit der RFC1323 gibt es zwei TCP-Erweiterungen:

1. TCP Window Scaling

Beim Einsatz von TCP Window Scaling wird im TCP-Header generell das max. RWIN (ohne TCP Window Scaling) eingesetzt und zusaetzlich ein Feld mit dem Window Scaling Wert gefuellt.

Die Formel fuer das RWIN mit Einsatz von TCP Window Scaling:

MSS x 44 x (2^Window-Scaling-Wert)

2. TCP Timestamps

TCP Timestamps nehmen jeweils 12 Byte von den Nutzdaten in Anspruch.

TCP Timestamps sollten nur genutzt werden, wenn bei groesseren Bandbreiten Probleme mit dem TCP Flow auftauchen oder es um genauere Berechnungen vom Durchsatz geht.

Der Windows-Registrykey TCP1323Opts (ebenfalls im genannten Pfad und vom Typ DWORD) kennt dafuer 4 Zustaende:

0 - TCP Window Scaling und TCP Timestamps aus

1 - TCP Window Scaling ein, TCP Timestamps aus

2 - TCP Windows Scaling aus, TCP Timestamps ein

3 - TCP Window Scaling und TCP Timestamps aus

Um zu ermitteln, welches RWIN fuer die benoetigte Bandbreite benoetigt wird, wird das Bandwidth Delay Product (bdp) genutzt.

2 x Linkspeed in bit/s x RTT in s /8

Bsp 100 Mbit/s im LAN

Im LAN hat man ueblicherweise eine RTT < 1 ms

2 x 100000000 bit/s x 0,0009 s /8 = 22500 Byte

22500 Byte ist groesser als der Standardwert von Windows (Win 9x ca. 8 KByte; ab Windows 2000 ca. 16 KByte)

D.h. Du musst zwar erhoehen, aber brauchst nicht das TCP Window Scaling.

Der max. moegliche Wert ohne Einsatz von TCP Window Scaling mit der Grundlage MTU 1500 (= 64240 Byte) reicht hier voellig aus.

Bei Gigabit-LAN mit einer MTU 1500 sieht es anders aus: 2 x 1000000000 bit/s x 0,0009 s /8 = 225000 Byte

Hier solltest Du TCP Window Scaling aktivieren und das RWIN auf 256960 Byte setzen.

Dann gibt es auch noch weitere TCP-Erweiterungen, die aus einem lahmen Anschluss etwas herausholen koennen:

TCP Selective Ack (RFC2883)

TCP Selective ACK Nachrichten ermoeglichen es den beteiligten Systemen auch mal zwischendurch TCP ACK Nachrichten zu senden, um zu signalisieren das ein Teil bereits empfangen wurde. Damit koennen auch erneute Uebertragungen (Retransmits) reduziert werden.

Windows Registry Key: SAcksOpts = 1

Forward Ack (FAck)

Mit Forward Acks kann angezeigt werden welche ACK Nachrichten nicht empfangen wurden und dient zur Erkennung von ueberlasteten Leitungen.

Kennt Windows leider nicht.

Wenn das betreffende System auch aus dem Internet erreichbar ist, musst Du entsprechende Werte fuer Deine Internetverbindung (bzw. in manchen Faellen fuer die angenomme Anbindung des Gegenuebers) setzen.

Bei Dateiuebertragungen im Windowsbereich wird CIFS (bzw. auch unter dem alten Namen SMB bekannt) eingesetzt.

Dort gibt es auch einen Buffer, den Windows bei der Installation nicht optimal setzt.

http://technet.microsoft.com/en-us/library/cc740106.aspx

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q320829

Hier als ersten Schritt 16 KByte auf Server- und Clientseite probieren und dann schrittweise ueber 32 zum Maximalwert 64 KByte erhoehen.

Bearbeitet 14. Dezember 2008 von hades

[b0nzai]

Vielen Dank für die ausführlichen Antworten!

Leider führte das Schrauben an der TcpWindowSize und SizReqBuf zu keiner Veränderung bei den Retransmits.

Ich habe immer konstante 73387 retransmits (pro 100MB, egal wohin).

[Crash2001]

Wie kommst du eigentlich auf die 73387 retransmits? Woher hast du den Wert?

Ich würde ja fast vermuten, dass du die übertragenen mit den erneut übertragenen Paketen durcheinanderschmeisst.

[b0nzai]

Ganz einfach:

netstat -s 1

Dann starte ich einen kopiervorgang vom laptop zum fileserver.

Ich kopiere ein nicht-kompremierbares 100MB Dummlyfile.

Wenn der Kopiervorgang abgeschlossen ist habe ich immaer 73.000 Retransmits.

[Crash2001]

Also da die "Segment Retransmits" unter dem Punkt "TCP Statistics for IPV4", richtig?

Die zählen also jedes mal, wenn du das laufen lässt um weitere ca. 70.000 hoch? Oder meinst du da steht immer ein Wert um die 70.000? Falls zweiteres, dann kommen keine Retransmits, da der Wert nicht bei jedem Start neu auf Null steht, sondern den alten wert behält. Nur wenn dort die Zahl um den entsprechenden Wert höher wird, würdest du also entsprechend viele Retransmits haben.

[b0nzai]

Nein, er zählt jedes mal auf 73.000 hoch. :-)

[hades]

Eine Dateiuebertragung unter Windows ist nicht nur TCP (was Du mit netstat siehst).

Da spielt auch noch CIFS(SMB) eine nicht gerade kleine Rolle.

Um die TCP-Durchsatzrate zu testen nimm ein geeignetes Tool, z.B. iperf.

Dann schaue auch nach wie die Interfaces eingestellt sind:

Auf beiden Seiten sollte bei 100Mbit-RJ45-Verbindungen entweder gleiche Werte fuer Speed und Duplex (full duplex in einem geswitchten Netz) stehen oder auf beiden Seiten Autoneg genutzt werden.

Wenn es Dein Switch hergibt, nimm unbedingt statische Werte.

Bei Gigabit muss Autoneg und auch die Flusskontrolle an sein.

Die genannten Registry-Einstellungen muessen auf Client- und Serverseite auf dieselben Werte angepasst werden, sonst bringt das nix.

Bearbeitet 15. Dezember 2008 von hades

[b0nzai]

Server und Clients sind beide auf 100MBIT Full duplex eingestellt.

Meiner Meinung nach kann es nicht am Server liegen.

1. Alle Windows 2000 Clients haben keine Retransmits

2. XP zu XP und XP zu 2000 Client -> Retransmits

3. 2000 zu XP und 2000 zu 2000 Client -> keine Retransmits

Aber ich werde das von dir empfohlene tool einmal ausprobieren!

[hades]

Hast Du nach der Registryaenderung neugestartet?

Nein... Dann hole das nach.

Schalte auch mal testweise saemtliche Sicherheitssoftware wie z.B. Virenscanner und Firewalls auf dem Client aus.

Was ist das fuer ein Server, von dem Du Dateien uebertraegst?

Windows 200x DC (auch Small Business Server)?

Ja -> Dann sollte fuer den Fileserver auf diesem System ein separates Hardware-RAID-Array angelegt sein. Sonst hast Du frueher oder spaeter Performanceprobleme, weil auf einem DC (auch SBS) die Partition mit dem AD grundsaetzlich ohne Schreibcache betrieben wird.

[b0nzai]

Hast Du nach der Registryaenderung neugestartet?

Ja, habe nach allen Regestryänderungen neugestartet.

Schalte auch mal testweise saemtliche Sicherheitssoftware wie z.B. Virenscanner und Firewalls auf dem Client aus.

Auf dem XP Testlaptop habe ich alles deaktviert. Frisch installiertes Windows XP SP3, Netzwerkkartentreiber. Firewall deaktiviert.

Ja -> Dann sollte fuer den Fileserver auf diesem System ein separates Hardware-RAID-Array angelegt sein. Sonst hast Du frueher oder spaeter Performanceprobleme, weil auf einem DC (auch SBS) die Partition mit dem AD grundsaetzlich ohne Schreibcache betrieben wird.

Der Fileserver ist ein Windows 2000 Server. Aber wie gesagt: Ich habe es nicht nur auf dem. Die Retransmits habe ich immer wenn ich von der XP Maschiene irgendwo ins Netz kopiere.

Ich glaube mittlerweile das es sich nur um einen Darstellungsfehler von netstat handelt. Ich habe keine Geschwindigkeitsunterschiede zwischen einem kopiervorgang mit 75.000 Retransmits und einem ohne gemessen.

Ich denke netstat interpretiert die übertragenen Pakete einfach nur fälschlicherweise als Retransmit.

[hades]

Noe, das sind schon Retransmits.

Deshalb sollst Du die Dateifreigaben mal beseite legen und TCP alleine z.B. mit iperf testen.

Erst wenn TCP performant arbeitet, kannst Du Dich den hoeheren Protokollen widmen.

Denn der Unterschied liegt auf jeden Fall schon mal im CIFS/SMB.

Z.B. werden bei XP ab SP2 und Server 2003 CIFS/SMB-Pakete standardmaessig signiert, bei 2000 und XP < SP2 nicht. Das Signieren ist zwar gut fuer die Sicherheit, frisst aber auch etwas Performance.

Andere Ursachen koennen fragmentierte Dateien in diesen Freigaben sein. Dann bremst die Festplatte Dich aus.