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
