On Fri, Mar 07, 2008 at 02:50:43PM +0100, Kovacs Peter Tamas wrote:
>
> I thought it might be a network problem, so I've run Wireshark on the
> capture machine, and looked at the trace. All I've seen is that packets
> are sent in 200 ms intervals. Some packets are sent our rapidly, then
> nothing happens for 200 ms, then another bunch of packets are sent. No
> errors, no warnings in the expert info, nothing strange. It's simply the
> host that waits ~200 ms for some unknown reason.
It does sound like "nagle" and "Delayed ACK" doing their dance together.
The nagle algorythm will make the tcp stack send out only frames of
size MSS (Maximum segment size) unless the previously sent data has
been ACKed. When all data has been ACKed, it will send all data in
it's send buffer (less then MSS octets).
Delayed acking will make the tcp-stack wait before sending an ACK
until a data frame needs to be sent. This makes it possible to
piggyback on the data-frame. Usually the time-out to wait for
data to be sent is 100ms or 200ms.
So, if the data that needs to be sent from host-1 to host-2 has a length
that is not a multiple of MSS octets, the last tcp-segment will not
be sent because of the nagle algorythm on host-1. Since host-2 does not
need to send any data back to host-1, it will wait till the time-out
before sending the ACK for the last segment with size MSS. When host-1
receives this ACK it will send the last segment.
For large transfers, the 100-200ms delay will not be a big problem, but
for small transfers it can really kill the performance.
> We've already tried TCP_NODELAY, now all our sockets are created with
> this, but it does not help. We tried changing the network adapters,
> increasing buffer sizes, nothing helped so far.
Did you enable TCP_NODELAY on the *receiving* end?
Another thing that might help is to send all data with the TCP PUSH
flag set. This should overrule nagle and make the tcp-stack send
it's data immediately.
Hope this helps,
Cheers,
Sake
