Der Nagle-Algorithmus hat aber mit der TCP_NODELAY-option zu tun und nix mit der TcpAckFrequency.
Doch hat er eigentlich schon. Denn er steht in einer Beziehung mit der TcpAckFrequency. Einmal hast du den Sender und einmal den Empfänger.
Der Nagle-Algorithmus soll verhindern, daß zuviele kleine Pakete durch das Netzwerk schwirren. Ein Paket, daß nicht voll ist, daß wird nur dann rausgeschickt, wenn kein Ack vorangegangener Pakete mehr aussteht. Und in welcher Abfolge die Ack's vom Empfänger kommen, wird ja durch die TcpAckFrequency bestimmt. Somit gibt es schon eine eindeutige Beziehung zwischen den Nagle-Algorithmus und der TcpAckFrequency meiner Meinung nach.
Ob es jetzt Sinn macht, daran zu schrauben, daß hängt vom Einzelfall ab.
So zum Beispiel wird durch die Angabe, daß jedes Paket sofort bestätigt werden soll, der Traffic erhöht. Das heißt, bei Verbindungen, die die Bandbreite bereits voll ausnutzen, geht der Schuß nach hinten los.
Ebenso nach hinten geht der Schuß los, wenn man möglicherweise mehrere Rechner an einen Hub angeschlossen hat. Denn die Anzahl der Kollisionen wird definitv ansteigen.
Oder etwa bei einen Rechner, der eigentlich fast nur Empfänger großer Daten ist. Auch hier macht es mehr Sinn, wenn er mehrere Pakete gleichzeitig bestätigt, als jedes einzeln. Dazu gibt es dann schöne Rechnungen, mit denen man die optimale RWin in Abhängigkeit von MTU und TcpAckFrequency errechnen kann.
