[LUGA] Mit freundlicher Unterstützung von:
init.at

Mail Thread Index


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[luga] TCP retransmissions: Gehört das so?



Beim Versuch herauszufinden, warum unsere Windoof-Rechner öfter
abstürzen, seit wir einen neuen, schnelleren HP-Server haben
(Zwischenruf aus dem Publikum: Off-Topic, wo bleibt Linux? Antwort:
Geduld!), habe ich per FTP zwischen diversen Linux- (der Zwischenrufer:
Ah!) und HP-Kisten 10MB-Files herumübertragen, und mit tcpdump (auch
unter Linux (der Zwischenrufer: Oh!)) zugeschaut.

Setting:

titan (schnell) und calypso (nicht so schnell) sind HP-Server die
mittels 100baseT (full-duplex) an einem Switch hängen. An diesem Switch
hängen auch mehrere 10base2-Segmente, an einem der beiden die beiden
Linux-Rechner octopussy und posbi.

Grobes Ergebnis: FTPs vom titan weg sind immer langsam (ca.
250-300kB/s). FTPs von der calypso zum titan schwanken zwischen 1300 und
1800kB/s. FTPs zwischen allen anderen erreichen ca. 800-900kB/s also
typische 10base2-Geschwindigkeit.

Tcpdumpen konnte ich nur in einem 10base2-Segment also hier als Beispiel
ein FTP von Titan zur octopussy, wobei der posbi mitschaut. Die
Übertragung geht immer eine knappe Sekunde lang schnell, dann ist eine
Sekunde Pause, dann geht's wieder schnell, ... Offensichtlich gehen da
Pakete verloren, und die Retransmission Timeouts sind ein bißchen lang.

Wenn man sich aber die Sache genauer ansieht, wird das ganze
mysteriöser:

20:17:15.780367 titan.ftp-data > octopussy.1358: . 439461:440921(1460) ack 1 win 57344 (DF)
[hier sind Pakete verlorengegangen]
20:17:15.780367 titan.ftp-data > octopussy.1358: . 449681:451141(1460) ack 1 win 57344 (DF)
[titan schickt weiter (Pakete gelöscht)]
20:17:15.790367 octopussy.1358 > titan.ftp-data: . ack 440921 win 31744 [tos 0x8]
20:17:15.790367 octopussy.1358 > titan.ftp-data: . ack 440921 win 31744 [tos 0x8]
20:17:15.790367 octopussy.1358 > titan.ftp-data: . ack 440921 win 31744 [tos 0x8]
20:17:15.790367 octopussy.1358 > titan.ftp-data: . ack 440921 win 31744 [tos 0x8]
20:17:15.790367 octopussy.1358 > titan.ftp-data: . ack 440921 win 31744 [tos 0x8]
20:17:15.790367 octopussy.1358 > titan.ftp-data: . ack 440921 win 31744 [tos 0x8]
20:17:15.790367 octopussy.1358 > titan.ftp-data: . ack 440921 win 31744 [tos 0x8]
20:17:15.790367 octopussy.1358 > titan.ftp-data: . ack 440921 win 31744 [tos 0x8]
[titan schickt weiter (Pakete gelöscht), überreißt dann offensichtlich, daß es schon die
längste Zeit (20 ms) ACKs fürs gleiche Segment bekommt und schickt das
erste verlorengegangene Paket:]
20:17:15.810368 titan.ftp-data > octopussy.1358: . 440921:442381(1460) ack 1 win 57344 (DF)
20:17:15.810368 octopussy.1358 > titan.ftp-data: . ack 440921 win 31744 [tos 0x8]
20:17:15.810368 octopussy.1358 > titan.ftp-data: . ack 440921 win 31744 [tos 0x8]
20:17:15.810368 octopussy.1358 > titan.ftp-data: . ack 440921 win 31744 [tos 0x8]
20:17:15.810368 octopussy.1358 > titan.ftp-data: . ack 440921 win 31744 [tos 0x8]
20:17:15.810368 octopussy.1358 > titan.ftp-data: . ack 440921 win 31744 [tos 0x8]
20:17:15.810368 octopussy.1358 > titan.ftp-data: . ack 440921 win 31744 [tos 0x8]
[Octopussy empfängt und ack diesen nach weitern 20 ms:]
20:17:15.830369 octopussy.1358 > titan.ftp-data: . ack 442381 win 30284 [tos 0x8]

[und jetzt ist Pause. titan schickt nicht, wie man erwarten sollte,
sofort das nächste Segment, sondern wartet gute 500ms:]
20:17:16.370389 titan.ftp-data > octopussy.1358: . 442381:443841(1460) ack 1 win 57344 (DF)

[es wird noch seltsamer. Auch octopussy ackt das Segment nicht sofort,
sondern wartet ebenfalls 500ms:]
20:17:16.870408 octopussy.1358 > titan.ftp-data: . ack 443841 win 28824 [tos 0x8]

[von jetzt an geht wieder normal weiter:]
20:17:16.870408 titan.ftp-data > octopussy.1358: . 443841:445301(1460) ack 1 win 57344 (DF)
20:17:16.870408 titan.ftp-data > octopussy.1358: . 445301:446761(1460) ack 1 win 57344 (DF)

Nach Durchlesen von RFC 793 und 1122 sehe ich, wie sowas passieren kann
(durch unglückliche Auslegung der Regeln für "fast retransmit" und
"delayed ack"), aber besonders intelligent scheint es mir nicht zu sein. 

	hp

Attachment: pgpYlcpZxlRcz.pgp
Description: PGP signature



powered by LINUX the choice of a gnu generation
linux user group austria;
Suche
Suche
Letzte Änderung:
webmaster@luga.at
September 2010