RELENG_8 ignoring TCP window size? [Was: Re: Help for TCP understanding wanted, ACK-MSS-Window [Was: Re: best practice to watch TCP parms of established sockets]]

[Harald Schmalzbauer]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20100218/a32f3f39/signature.pgp