Part of the issue is that NODELAY has dual meaning. It means don't delay acks (on receiver), and don't coalesce writes (on sender). If java didn't turn on NODELAY, it would get coalescing but it would then get delayed acks.
Ah, this is the first time I've heard that TCP_NODELAY on a receiver would alter the ACK policy. I don't think it does that on other stacks. That sounds like a nasty double-whammy when both sides are using it.
If you look at the packet flow,
Was there a trace posted somewhere? I would indeed like to look at it. I'd be quite happy to slam java it it happened to be putting logically associated data onto the connection in separate send calls :)
it is the typical RPC style flow and actually would benefit from delayed acks as well. The ACK would piggyback on the response to the initial request and that would give better performance.
I take it with this Java stuf there is more than one of these request/response things in flight at one time?
X is different because, it is not request/response based. The mouse moves you want the packet to be sent. Something is painted, you want it displayed. Delayed ack's would only slow perceived response.
I was with you until the last bit. If X is setting TCP_NODELAY the sending isn't waiting for ACK's, delayed or otherwise (modulo the cwnd) so how would delayed ACK's slow perceived response? I would think that once you have TCP_NODELAY on the sender, the ACK policy becomes a don't care.
rick jones - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
