slow tcp acks on loopback device
smfltc at us.ibm.com
Fri Jul 22 21:42:40 GMT 2005
> TCP_NODELAY does not control ACK generation, instead it modifies
> the Nagle algorithm behavior when sending data packets.
Looks like RHEL4 had an odd default smb.conf on the server side - the
RedHat smb.conf seems to set SO_RCVBUF and SO_SNDBUF to 8K (reducing
them from their default). This seems very odd since common TCP frame
sizes for this protocol (SMB/CIFS) will be just over 16K (the negotiated
SMB buffer size) as well as even large frames, 60K, for large read/write
requests which Windows sends. Removing the SO_SNDBUF, SO_RCVBUF options
(as in the smb.conf for other distros), increased performance a lot.
The Samba Howto recommends against setting them so small as well.
The alternative solution configuring the client end - altering ack
behavior to allow the client to do quick(er) acks probably would have
helped too, but of course has sideeffects (more acks) and it was not
obvious to me how to do that safely from a kernel vfs module.
More information about the samba-technical