Speed up MacOS X file transferring over network

We had an issue with a group of MacOS X clients on a particular VLAN that were experiencing painfully slow transfers (~100KB/s) to our Solaris fileservers running netatalk (AFP). The problem was solved by tweaking a kernel parameter on the client that made it “more compatible.”

delayed_ack=0 responds after every packet (OFF)
delayed_ack=1 always employs delayed ack, 6 packets can get 1 ack
delayed_ack=2 immediate ack after 2nd packet, 2 packets per ack (Compatibility Mode)
delayed_ack=3 should auto detect when to employ delayed ack, 4 packets per ack. (DEFAULT)

Get the current value for net.inet.tcp.delayed_ack (default is 3)

$ sudo sysctl -a net.inet.tcp.delayed_ack
net.inet.tcp.delayed_ack: 3

Let’s try changing it to 2 and you should immediately notice a difference (this worked for us, you may also try values of 0 and 1)

$ sudo sysctl -w net.inet.tcp.delayed_ack=2
net.inet.tcp.delayed_ack: 3 -> 2

I’m not sure why OSX ships with a default of “3.” Our software vendor also did not know, nor did our enterprise Apple support. All I do know, is that Google is filled with people experiencing the same problems as far back as ten years ago. This fix is good for all sorts of network weirdness and compatibility issues with Samba, netatalk, FreeBSD, Solaris, Windows, etc etc.

To make this persistent across reboots you will need to use /etc/sysctl.conf. If this file does not exist, create it, or use the following command.

$ echo "net.inet.tcp.delayed_ack=2" | sudo tee -a /etc/sysctl.conf

You can read more here:
TCP Performance problems caused by interaction between Nagle’s Algorithm and Delayed ACK

3 comments

  1. Thanks a lot for this tip, after upgrading to Mountain Lion and netatalk 2.2.2 the slowdown was unbearable.

    Altering this parameter fixed it like a shot!

  2. This article is over two years old as I post this comment, but the problem is still current and there is still not much help to be found in a Google search.

    Your link to the article on Nagle’s algorithm interaction with delayed ack led me to figure out perhaps a better fix and an explanation for Apple setting the default delayed_ack option to 3.

    We were seeing a huge slowdown when reading from an SMB (samba) linux share mounted on a Mountain Lion client. Your suggestion of changing delayed_ack from 3 to 2 sped up one test copy of a 150MB file over gigabit ethernet from 15 minutes to under 8 seconds. But the article you linked to revealed the real problem. The setting in smb.conf on the server contained

    socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

    According to your chart delayed_ack=3 sends an ack every 4 packets. The 8192 window size is 5 and a fraction packets, one and a fraction packet more than the number used by delayed_ack, exactly the failure scenario described in the article.

    The fix was to increase the buffer size used by the server. I did what is recommended in the O’Reilly book Using Samba in the section

    http://oreilly.com/openbook/samba/book/appb_02.html#appb-19919

    and increased the values checking the performance to see the best results. In my case it was

    socket options = TCP_NODELAY SO_RCVBUF=32768 SO_SNDBUF=32768

    With that buffer size the default delayed_ack=3 setting on the Mac was the option which got the best results in my tests, running it in under 4 seconds, more than twice as fast as I got only changing to delayed_ack=2 with the smaller buffer size, and by a small degree the fastest option with the larger buffer size. So Apple’s default setting can make sense to use.

    In our case the slowdown was only in reading Samba shares, and the fix was changing the window size in the Samba configuration file. If you see problems with AFP or in all reads over the network, you might have to look for corresponding settings for AFP or the network in general on the server. But it does appear to be critical to have the TCP buffer size big enough so that you do not end up with one and a fraction packets left sitting in it after the Mac has received its four packets that could trigger the ack delay.

  3. Thanks for posting this! I was having trouble using a WD My Cloud NAS and was about to return it when I happened across this. In fact, the Level 2 tech from WD that worked with me and had Macs at his own home didn’t even know about this.

Leave a Reply

Your email address will not be published. Required fields are marked *


− one = 4

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>