Harald Schmalzbauer wrote:
Some experimental results:
When rsyncing with windows, and FreeBSD is receiver, I see the same
ACK ever two segemnts, but speed is at 72MB/s.
When FreeBSD is sender and Windows is receiver, it looks more I
expected. There are about 20 data segments before a ACK is returned.
And there are TCP Window Update Segments, reflecting smaller receiver
buffers on the windows side. But this happens at a throughput of
82MB/s!!! So the windows machine is behaving like I understand the TCP
flow control.
Any explanation why the FreeBSD machine seems to ignore window size?
Yes, here we are in RFC1122:
4.2.3.2 When to Send an ACK Segment
A host that is receiving a stream of TCP data segments can increase
efficiency in both the Internet and the hosts by sending fewer than one
ACK (acknowledgment) segment per data segment received; this is known as
a "delayed ACK" [TCP:5].
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.
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?
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
