[PATCH] Added NoDelay config option and nodelay subsystem option

[Rick Jones]

> Let's see if I can explain it.  Consider a channel with a 2 s RTT,
> infinite throughput, infinitely fast computers, no window updates, and
> a Nagle timeout of 0.2 s.  The write column is the time the
> process calls write(), and the send column is the time the TCP stack
> releases the packet on the wire.  Req is a small request packet
> (<<MSS), and Rsp is a large response packet (>>MSS).

There is no such thing as a Nagle timeout.  There is a delayed ACK
timeout. Indeed, the two interact, but they should not be merged :)

> Write  Send   Signal     Arrival
> -----------------------------------
> 0.0    0.0    Req#1 ->   1.0
> 0.01   0.2    Req#2 ->   1.2   (nagle delay)
> 1.0    1.0    <- Rsp#1   2.0
> 1.2    1.2    <- Rsp#2   2.2
> 2.0    2.2    Req#3 ->   3.2   (nagle delay)
> 2.2    2.4    Req#4 ->   3.4   (nagle delay)
> 3.2    3.2    <- Rsp#3   4.2
> 3.4    3.4    <- Rsp#4   4.4
> 
> Did I get it right, or did I miss something?  As you can see,
> transmitting four data packets took 4.4 seconds.  Without Nagle, it
> would have taken 4 second.

On balance I think you got it right. If you do not ever have enough
reqest/response data to match the bandwidth delay product of the link,
you will probably have the occasional delay from Nagle and Delayed ACK. 

As you get closer and closer to matching the bandwidth delay product,
the responses/requests will start clocking each other onto the network,
and you will no longer "see" the dleayed ACK timouts in the transfer
rate.

rick
-- 
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...