Patrick Mahan schrieb am 18.02.2010 16:20 (localtime):
See inline...
...
Please clarify my TCP understanding.
If I have the window set to 65535 in the header and a MSS of 1460, how often should the receiver send ACK segments? window/MSS, right?

How soon you see the ACK is based on two values in the kernel:
   net.inet.tcp.delacktime
   net.inet.tcp.delayed_ack

The first one controls how soon the peer replies with an ACK if there is
no data to send back, ie. it is just a plain ack.  Van Jacobson first
recommended it in the early days of TCP/IP.  Historically, it has been
implemented as a 200 ms timer, but in FreeBSD it is a 100 ms timer.

Thank you for your hint. I heard of that but never thought about it, because 100ms is a magnitude higher than my µs LAN delay and since I'm not suffering from extremeley slow speeds.

...
a) why disabling net.inet.tcp.rfc1323 gives slightly better rsync throughput than enabled

rfc1323 deals with window scaling and timestamp options.  Perhaps these
are getting in the way?

b) why I can't transfer more than 50MB/s over my direct linked GbE boxes.

But right now I even don't understand the dump I see. As far as I understand I should only see every 45 data segments one ACK segment. That would clearly explain to me why I can't saturate my GbE link. But I can't imagine this is a uncovered faulty behaviour, so I guess I haven't understood TCP.


No we are also seeing similar behavior over the em(4) interface under
FreeBSD 8.0-Stable.

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?

Thanks,

-Harry

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to