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