Unfortunately, reading large files from Mac OS X is incredibly slow. Adding the following to /etc/sysctl.conf solves this annoying problem:
net.inet.tcp.delayed_ack=0This configuration file does not exist in a default installation so simply create it from scratch. rc(8) takes care of it automatically.
11 comments:
NetBSD doesn't have this sysctl, so I guess it doesn't delay ACK's at all? Apple must have gotten it from FreeBSD, which has it, and also defaulting to 1.
I wonder in which cases this actually *improves* networking performance, and esp. improves it enough to justify the on-by-default setting? (with SMB or other large-and-one-directional traffic it's an obvious drawback, as you have experienced).
No idea on what NetBSD does and also don't know why this is tunable in FreeBSD and OS X...
Based on the sysctl name, I deduce that what this does is wait for an ACK before the following packet is sent. But Stop-and-Wait is (almost?) always slower than an ARQ protocol...
This is what FreeBSD's tuning(4) manpage says about it:
The net.inet.tcp.delayed_ack TCP feature is largly misunderstood. Historically speaking this feature was designed to allow the acknowledgement to transmitted data to be returned along with the response. For example, when you type over a remote shell the acknowledgement to the character you send can be returned along with the data representing the echo of the character. With delayed acks turned off the acknowledgement may be sent in its own packet before the remote service has a chance to echo the data it just received. This same concept also applies to any interactive protocol (e.g. SMTP, WWW, POP3) and can cut the number of tiny packets flowing across the network in half. The FreeBSD delayed-ack implementation also follows the TCP protocol rule that at least every other packet be acknowledged even if the standard 100ms timeout has not yet passed. Normally the worst a delayed ack can do is slightly delay the teardown of a connection, or slightly delay the ramp-up of a slow-start TCP connection. While we aren't sure we believe that the several FAQs related to packages such as SAMBA and SQUID which advise turning off delayed acks may be refering to the slow-start issue. In FreeBSD it would be more beneficial to increase the slow-start flightsize via the net.inet.tcp.slowstart_flightsize sysctl rather then disable delayed acks.
Ah, cool. That explanation makes a lot of sense. But the suggestion of increasing net.inet.tcp.slowstart_flightsize doesn't seem to improve anything, at least not under OS X. I tried multiple values between 1 and 100k and Samba transfers are still very slow (which is not true for other protocols).
Probably because SMB file transfers are completely one-directional traffic, which gives no data packets in the opposite direction to piggy-back the ACKs on? (just a guess...)
http://mail-index.netbsd.org/tech-net/2003/01/28/0004.html
-- Pavel Cahyna
I dont know how automate the command on Max OS 10.4
Thanks
>I dont know how automate the command on Max OS 10.4
According to wikipedia, do this:
add the line to the file:
/etc/sysctl.conf
Holy cow, nice find. I'm new to Macs and I was shocked at how bad the CIFS performace was. Not anymore after this setting.
I had the same kind of problem - Copying files with Samba was quite slow with OS X (10.4.11) and changing the net.inet.tcp.delayed_ack setting seemed to fix it with me, thanks!
The setting can be evaluated also with console (root access needed) by running
sysctl -w net.inet.tcp.delayed_ack=0
Thanks so much!!!
This saved me a bunch of time..
Post a Comment