Stephen Hurd 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?
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?
If the problem is the ACKs from the Windows system, you should be seeing
a large number of retransmits from the FreeBSD system (on the order of
one retransmit per five packets). Is this what you're seeing? If you
have a capture you could share covering a few seconds, I could take a
look and provide a better opinion.
_______________________________________________
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"
