Messages in this thread | | | Date | Fri, 22 Jul 2005 13:08:16 -0700 (PDT) | Subject | Re: slow tcp acks on loopback device | From | "David S. Miller" <> |
| |
From: Steve French <smfltc@us.ibm.com> Date: 22 Jul 2005 14:56:59 -0500
> Noticing that the loopback device (at least on RHEL4) has an unfortunate > mtu size 16384 (which is about 50 bytes too small for SMB read > responses), I did try increasing the MTU slightly. Changing that to > 18000 did avoid the fragmentation and the 40ms delay - but what puzzled > me was why setting TCP_NODELAY after the socket was created did not > eliminate the delay on the ack and if there is a way to avoid the huge > tcp ack delay by either doing something else to force client acking > immediately or to do something on the client side of the stack to get > the server to send the whole 16K+ frame - it looks like the tcp windows > is 32K if the value in the tcp acks in the network trace is to be > trusted.
TCP_NODELAY does not control ACK generation, instead it modifies the Nagle algorithm behavior when sending data packets.
Please take networking discussions to netdev@vger.kernel.org which is where the networking developers are. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |