Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

A possible fix for very slow AirPort transfer speeds Network
Yesterday, the hard drive in my 12" PowerBook G4 (purchased in April, 2004) died a horrible, painful death. After doing some testing on the machine (it typically doesn't hold any critical data, so it's an ideal test platform), it failed to reboot. Long story short, the hard drive was dead. Really dead -- Disk Utility told me "This drive has reported a fatal hardware error to Disk Utility. If the drive has not failed completely, back up as much data as you can and then replace it with a working drive." Thankfully, it then mounted in a partially-usable state, and I was able to retrieve the one bit of non-backed up data on the drive (my wife's Palm Pilot contacts, which contained updates she hadn't yet synched back to the Pilot).

After installing a new drive and reinstalling 10.5.2, I set about copying key files and programs back to the machine. However, my AirPort performance was glacially slow: time estimates to copy 70MB of data were in excess of 45 minutes! Some Google searching told me that I was not alone. Apparently this is a pretty big issue for many people on 10.5.2, but it's not universal -- our MacBook Pro, for instance, sees no such slowdowns.

I haven't marked this hint as 10.5 only (as the solution can be implemented on 10.4, too), but it does seem that the problem is limited to those running 10.5.2, and using AirPort on either Intel or PowerPC machines. Read on for the solution...

That linked thread from Apple Discussions contains a potential fix. John Albergo theorized that it might be related to the TCP setting for "delayed_ack", and offered this one-line Terminal solution:
sudo sysctl -w net.inet.tcp.delayed_ack=0
The default setting is three; the above command changes it to zero until the next restart. (For a permanent fix, John linked to this blog post that contains a Startup Item to run the above command at each boot.)

I tested it last night, and it worked perfectly on our troublesome PowerBook -- AirPort speeds returned to normal immediately after running the command. Theoretically, setting delayed_ack to zero is a Bad Thing, especially on a slower network. However, I transferred over 250MB worth of stuff (both data and applications) last night, and everything worked perfectly. Note that others have reported that the fix didn't work for them, but many people are reporting success.

In my case, I've chosen not to install the startup item -- assuming Apple figures out the real cause of this problem and fixes it in 10.5.3, I don't want to have to remember to remove the startup item. The PowerBook is only ever restarted for software updates, so I've just put the command into a simple one-line script for easy running when needed after the occasional restart.

Ironically, this very fix was listed here in this hint from a couple years back (and even earlier, in the comments to this hint). However, those solutions didn't come up when I searched for a solution to the problem last night, because they're about Samba and Windows file transfer speeds, and don't mention AirPort.
  • Currently 2.33 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (6 votes cast)

A possible fix for very slow AirPort transfer speeds | 11 comments | Create New Account
Click here to return to the 'A possible fix for very slow AirPort transfer speeds' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
A possible fix for very slow AirPort transfer speeds
Authored by: acaltabiano on Mar 05, '08 09:48:26AM

That's now like 4-5 times I've seen that terminal command referenced online in the last week. Popular week for that lil' trick!

timing has an awful lot to do with the outcome of a raindance

[ Reply to This | # ]
A possible fix for very slow AirPort transfer speeds
Authored by: acdha on Mar 05, '08 10:52:47AM

n.b. an easy way to have that run at bootup is simply to add "net.inet.tcp.delayed_ack=0" to /etc/sysctl.conf - the system boot process already loads settings from that file.

[ Reply to This | # ]
A possible fix for very slow AirPort transfer speeds
Authored by: Felix on Mar 05, '08 12:04:09PM

I hope the original author of this Terminal solution ultimately gets credit for a great interim fix because every time I've seen it this week there's a different name attached.

And BTW, it worked for me.

I trust Apple's software developers will come up with a well-tested permanent solution which will work with all platforms.

[ Reply to This | # ]
What Delayed ACK Means
Authored by: jaaronp on Mar 05, '08 01:18:15PM

I was a bit curious about this hint (I have an MBP that suffers from poor airport performance) and wanted to find out what the delayed_ack setting did, why setting it to 0 might be helpful, and if so why the default value is 3.

The delayed_ack setting controls the amount of time the kernel waits before sending a TCP ACK packet to acknowledge the receipt of some incoming data. This is considered an optimization because in many cases network communications are bidirectional so it is likely to be the case that the application which just received a packet is about to send some data to the original sender of the packet. By waiting a little while the OS gives the application time to generate a response which can then be combined with the ACK packet. This means only one packet is sent instead of two (one for the ack and one for the application's response).

Even in a typical asynchronous protocol (like fetching a webpage for example where the server is sending lots of data and the web browser is unlikely to need to send a response), delaying the ACK doesn't cause any serious latency problems because the sender needn't wait for ACK packets before sending more data. The penalty of having to resend some earlier portion of the data (if an ACK packet is never received) is relatively low since the data is relatively small and likely to be cached somewhere.

For a large block transfer, like copying a multi-gig file using a networked filesystem, the penalty can be dramatic since the volume of data is too big to fit in the cache and the seek time penalty of having to go back and reread an earlier piece of the file is so large. It is likely that to avoid this penalty filesystem servers wait for acks before moving updating their cache (this is probably implemented as a ring-buffer so that the number of pending acks is never greater than some fixed value and as soon as one is received new data can be sent).

This is why setting the delayed_ack to 0 improves performance of large block transfers across a high-bandwidth lossy network (like 802.11g). If the server is able to determine more quickly that the client has received a chunk of the data, then the ring buffer can be advanced and new data can be loaded and sent. If the client always waits 100ms before sending the ack then the server will be constantly filling its buffers and waiting to receive an old ack (which may never arrive). Which leads to jerky performance and thus an overall slow transfer speed.

[ Reply to This | # ]
What Delayed ACK Means
Authored by: jaaronp on Mar 05, '08 01:28:25PM

I should note that in the previous comment my explanation of what TCP Delayed ACK means is based on actual facts. My explanation of why setting it to 0 is helpful is conjecture.

[ Reply to This | # ]
What Delayed ACK Means
Authored by: sblasl on Mar 05, '08 01:57:26PM

The description for Delayed ACK in the application Mac Pilot shows the following:

"Delay ACK to try and piggyback it onto a data packet. 0=disabled; 1=enabled; 2=more compatible (TH_PUSH); 3=streaming detection;"

So by using "0" we are disabling this parameter.

Mac Pilot will allow you to change the parameter on a permanent basis if you so choose to do so.

[ Reply to This | # ]
A possible fix for very slow AirPort transfer speeds
Authored by: madsteer on Mar 05, '08 03:46:17PM

Correct me if I'm wrong, but that Ack delay setting doesn't appear to be related to the Airport card, versus the ethernet card. It would be interesting to see if that setting has any affect over a 100/1000MBS wired connection too.

[ Reply to This | # ]
A possible fix for very slow AirPort transfer speeds
Authored by: zoltri on Mar 05, '08 04:45:00PM
I found this article fully explained the underlying issues, "a TCP performance problem resulting from a little-known interaction between Nagle's Algorithm and Delayed ACK". It is a long standing issue relating to optimizing the TCP data packets, TCP segment size and ACKs.

[ Reply to This | # ]
A possible fix for very slow AirPort transfer speeds
Authored by: T0b1 on Mar 06, '08 12:27:03AM
I got around this bug a loooooooong time ago with samba. This goes even back to 1997 one should think Apple got around fixing it. But then again its Apple ....


This bug has been documented for quite some time now, and NetBSD fixed. It thusly (this is from the tcp_input.c CVS log):

revision 1.37
date: 1997/12/11 06:33:29; author: thorpej; state: Exp; lines: +19 -9
Fix the "stretch ACK violation" bug documented in internet draft
draft-ietf-tcpimpl-prob-02.txt. Also, fix another bug in the header
prediction case where an ACK would not be sent when it should be.

I know the person who was bitten by this reported it to a clueful friend
at Apple, but it was not fixed for the Jaguar release.

Of course, Apple *should* have used NetBSD's TCP, but they had people
beating the FreeBSD drum there, and now all of us Mac users have the
pleasure of experiencing the consequences of that choice.

[ Reply to This | # ]
A possible fix for very slow AirPort transfer speeds
Authored by: djdawson on Mar 06, '08 08:31:41AM

Another, easier way to make this change permanent is to just create the file "sysctl.conf" in the "/etc" folder and put the appropriate command line in there. Do a "man sysctl.conf" in the terminal for details. Note that you'll need to use admin privileges to do this (e.g. "sudo").

[ Reply to This | # ]
A possible fix for very slow AirPort transfer speeds
Authored by: apple3.14159 on May 23, '09 09:08:36AM

Thank you, to whomever posted this solution! I was at wits end until I saw a marked difference between the ethernet port and the airport.

[ Reply to This | # ]