TCP delayed acks not being delayed?

[RW]

On Saturday 25 March 2006 21:25, Bill Moran wrote:

> Are you sure you're not exceeding the capability of the system to delay
> acks?

I would have thought not, it maxes-out with a receive space of 15k, and 
increasing the setting from 20k to 32k had no effect.

> Besides, when you're transferring data in one
> direction only, it doesn't make sense to delay empty acks.  only on a
> full-duplex transmissions do you get a benefit by taking measures to
> ensure that all packets have data.  When you're downloading, _all_ your
> acks are empty, so who cares?

I though I might be seeing a bug.  I was only measuring it because I was 
thinking of switching to pf/altq and I wanted to know how much to allow for 
empty-acks. 

However, I hadn't done the arithmetic before, and I was surprized to see that 
13% of my upload was being used. On a 4MB connection, that would be over half 
the bandwidth. Delayed acks don't affect the download speed on one tcp 
connection, but they could improve the performance of other traffic, when a 
download is taking place over a very asymmetric link.

> Additionally, if the client application turns nagle off, this will
> disable the use of delayed acks.  For things like file transfer, it's
> pretty much typical practice to disable nagle,

I guess that explains it.