Stephen Hemminger wrote:
Also, even if the TCP connection stalls for the ACK, why does it take multiple
miliseconds for the ACK to come back over the localhost?

Thanks,
Ben



NODELAY effects whether we send the second message right away (without waiting 
for
the first ACK).

And it also disabled nagle, right?

The delaying of acks happens unless TCP_QUICKACK is set on receiver.
It helps because if application is request/response and uses large
write's you would see:

So in this Skunkworx's case, assuming TCP_QUICKACK is not set, the receiving 
socket is
waiting for around 40ms before sending the ACK hoping that it will receive
more in the meantime and/or that it can piggy-back the ACK on a response data
packet?

I guess a more basic questions:  If someone is using relatively default sockets
(ie, not twiddling with NODELAY and QUICKACK), are we expected to see worse 
performance
over localhost and/or remote machine connections for small writes when using 
2.6.14+?

Thanks,
Ben

--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc  http://www.candelatech.com

-
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

Reply via email to