Help for TCP understanding wanted, ACK-MSS-Window [Was: Re: best
practice to watch TCP parms of established sockets]
h.schmalzbauer at omnilan.de
Thu Feb 18 12:57:39 UTC 2010
Harald Schmalzbauer schrieb am 17.02.2010 20:15 (localtime):
>>> Now my first idea is to compare MSS and windows sizes before and after the performance drop.
>>> How do I best capture them? tdpcump? It's GbE linkspeed...
>> It seems more likely that ZFS is running into slowdowns from resource contention, memory fragmentation, etc than your network would suddenly drop out, but tcpdump -w outfile.pcap is a good method of looking....
> Thanks, but fisrt tests showed that ZFS is not causing the slowdown.
I got exactly the same limitations when using tmpfs. So for now I'll
concentrate on that, back to ZFS later.
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?
Now I see every two segments acknowledged in my dump (rsync between two
I'd like to understand
a) why disabling net.inet.tcp.rfc1323 gives slightly better rsync
throughput than enabled
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
Thanks in advance,
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 196 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20100218/5a5f2e42/signature.pgp
More information about the freebsd-stable