10.4 und delayed ACKs

22/08/2007 - 19:58 von Ralph Böhme | Report spam
Nachdem der Thread "MBP und NAS" [1] Dank no archive schon halb vom
Nichts aufgefressen ist fange ich hier mal neu an.

Ergebnis:
Mindestens Solaris 10 und FreeNAS(->FreeBSD[5.3|6.2]) haben
offensichtlich mit OS X 10.4 stretch ACK Verhalten ein Problem.

(vereinfachte) Defintionen:
einfaches ACK (0):= jedes empfangene Packet wird bestàtigt
delayed ACK (2):= jedes zweite statt jedes empfangene Paket wird
bestàtigt
stretch ACK (1+3):= beobachtetes Verhalten zeigt ACKs alle 4-8
empfangenen Pakete

Siehe:
<http://tools.ietf.org/html/rfc1122>, 4.2.3.2
<http://tools.ietf.org/html/rfc2581>, 4.2

Stretch ACK wurde als Name für dieses Verhalten in RFC2525, 2.13
eingeführt(?) und beschreibt dieses als Fehlverhalten.
Siehe <http://tools.ietf.org/html/rfc2525>.

Solaris (>9 ?) und OS X 10.4 im Gegensatz zu Linux (was ist mit *BSD?)
implementieren dieses Verhalten aber als Standardverhalten. Siehe z.B.
<http://docs.sun.com/app/docs/doc/81...a=view>
#tcp_deferred_acks_max.

Offensichtlich kommen hier einige TCP Stacks auf Senderseite damit nich
so ganz zurecht, wenn der Client stretchACKed. Lustiger^WInteressanter-
weise auch Solaris 10 selbst.

Das Problem àußert sich folgendermaßen:
1. Server schickt 4-7 Pakete an den Client
2. Client ACKed alle empfangenen Pakete
(1.+2) n-mal, n grob zw. 20-40
Dann:
(im rcvWindow ist noch Platz, höheres Protokoll hat noch Daten, auch
sonst kein Grund vorhanden)
- der Sender hört auf zu senden
- nach einer Zeitspanne von 190-200 ms schickt der Client ein ACK
worauifhin der Server weitersendet. Dies tritt dann gerne mehrfach
pro Sekunden auf. Ergibt Performanceeinbrüche bis weit runter in den
KByte/s Bereich.

Abhilfe:
net.inet.tcp.delayed_ack=2

Jemand Einsichten zu teilen?

Ralph

[1] <http://groups.google.com/group/de.c...ale-netze/
browse_thread/thread/1f661c289187af46/65a637c197adabe8#65a637c197adabe8>
 

Lesen sie die antworten

#1 Noses
23/08/2007 - 18:48 | Warnen spam
私の記憶が確かならば, Ralph Böhme wrote:
Abhilfe:
net.inet.tcp.delayed_ack=2

Jemand Einsichten zu teilen?



Ja: Auch Deine Lösung (das "Fenster" zu verkleinern) ist nicht wirklich zu
empfehlen, denn idiotischerweise bringt das OS dann fertig, ack auf ack auf
Daten piggyzubacken (wie übersetzt man das - "auf den Schweinearsch zu
binden"?) Das ist nicht viel besser als die Ursprungsmethode. Wirklich
Standardkonform ist nur ein delayed_ack=0 und sollte von Dir nicht anders
auf Kunden losgelassen werden. Die paar ack-Pakete machen in einem
ordentlichen Netz auch nichts mehr aus.

Das da

net.inet.tcp.sendspace: 32768
net.inet.tcp.recvspace: 48000

net.inet.udp.recvspace: 42080

ist wesentlich tragischer und sollte deutlich höher ausfallen (ich nehme
normalerweise 256k).

kern.ipc.maxsockets: 512

ist eine weitere Zumutung.


Noses.

Ähnliche fragen