Re: 2.4 delayed acks don't work, fixed

["David S. Miller" <davem@redhat.com>]

   From: Andi Kleen <ak@suse.de>
   Date: Wed, 19 Mar 2003 02:55:17 +0100

   > This streamer application should buffer at the sending side, in order
   > to keep the window full.  Introducing artificial delays on the sending
   > side of a unidirectional TCP transfer is really bad for performance
   > and I can assure you that more than just "weird delayed ACK" behavior
   > will result.
   
   The broken tail append patch I did some time ago was supposed to address 
   that (better merging of writes on the sender side even for non SG
   NICs). Perhaps it should be rechecked.
   
   It may fix this.

I think we're talking about independant problems.

This streamer application buffers, but once the buffer is fully pushed
to the other end and the "receiver catches up", we get periodic sends
created at the rate of device data creation.  This cannot fill the
pipe between sender and receiver, thus TCP behaves suboptimally.

TCP needs at least a full window of data on the send side to clock
things properly.  This streamer application doesn't give TCP that
after it's initial send buffering is been shrunk.