Stephen Hurd schrieb am 18.02.2010 17:09 (localtime): ...
A TCP SHOULD implement a delayed ACK, but an ACK should not be excessively delayed; in particular, the delay MUST be less than 0.5 seconds, and in a stream of full-sized segments there SHOULD be an ACK for at least every second segment.
That's why I asked for help understandig TCP. I'm surely wrong then. I thought the ACK segment gets sent after the transfer of n segments equals windows-size. I don't undesrtand that window size yet... I'm back into my books
The idea of delayed ACKs is to allow an ACK to be sent with data if there will be data sent right away, not to combine ACKs... leaving out ACKs makes calculation of RTT problematical which causes performance problems all over the place... maybe the dearth of ACKs from the windows system is causing the problem?
The problem is not with the windows box, these transfer rates are sensible. The problem is with two RELENG_8 machines.
I'm doing this whole thing because I observed slowdowns under 20MB/s and I try to reproduce and investigate this. But first I have to get the idea right... If I don't understamd things going on when transfers make sense, I won't be able to determine what happens when transfers are slowed down...
Thanks, -Harry
signature.asc
Description: OpenPGP digital signature
