> 
quoted text
> Most of the apps where people care about this enough to complain to 
> their vendor (the cases I hear about) are in messaging apps, where 
> they're relaying a stream of events that have little to do with each 
> other, and they want TCP to maintain the integrity of the connection and 
> do a modicum of bandwidth management, but 40 ms stalls greatly exceed 
> their latency tolerances.

What _are_ their latency tolerances?  How often are they willing to 
tolerate a modicum of TCP bandwidth management?  Do they go ape when TCP 
sits waiting not just for 40ms, but for an entire RTO timer?

quoted text
> Using TCP_NODELAY is often the least bad option, but sometimes it's
> infeasible because of its effect on the network, and it certainly
> adds to the network stack overhead.  A more tunable Nagle delay would
> probably serve many of these apps much better.

If the applications are sending streams of logically unrelated sends 
down the same socket, then setting TCP_NODELAY is IMO fine.  Where it 
isn't fine is where these applications are generating their logically 
associated data in two or more small sends.  One send per message good. 
Two sends per message bad.

BTW, is this magical mystery Solaris ndd setting "tcp_naglim_def?"  FWIW 
I believe there is a similar setting by the same name in HP-UX.

rick jones
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html