Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Copying a file using AFP took 40 minutes but using scp it only took 7 mins. Why is AFP so slow?

My setup:

  • D-Link DIR-300 wifi router
  • iMac with Snow-Leopard serves AFP
  • Macbook with Leopard is the client
share|improve this question
up vote 6 down vote accepted

Just a hunch but it's quick to test. Try doing this on both Macs:

sysctl net.inet.tcp.delayed_ack

...note what it reports. It'll be an integer, probably the value 2 or 3...then set it to zero:

sudo sysctl -w net.inet.tcp.delayed_ack=0

...then on the AFP client, unmount all AFP-mounted volumes and re-mount them so that you're establishing new TCP connections. Then try your file copy test again and see if the speed is significantly improved.

I've run into situations where Mac OS X's TCP Delayed Ack algorithm was less than optimal, so it may be good to do this test to quickly rule that out.

share|improve this answer
This worked, thanks! btw is there a benefit in delaying acks? – yairchu Mar 26 '10 at 10:39
If you're receiving a continuous stream of data like a pure TCP data transfer (i.e. like HTTP and FTP do, not one that's broken up into separate block read operations like AFP or SMB might do) or doing audio or video streaming, then you can save bandwidth in the other direction (and processing effort) by acking only every few frames instead of every single frame. – Spiff Mar 26 '10 at 17:39
This doesn't work. Now what? – adib Apr 26 '11 at 6:52
@adib, why don't you ask a new Question with the details of your particular problem? – Spiff Apr 26 '11 at 20:23
Odly enough, these steps made the situation about 4times worse. from 11 minutes to transfer a large file, to 45 minutes. – deweydb Mar 17 '14 at 6:45

I read AFP has very small packet sizes, this could be working poorly with your wifi especially if you have encryption enabled. It could be that even a small amount of packet loss is killing you, or the encryption overheads (on small packets) could be eating all your bandwidth.

Either way are you solving a problem here? Why not just use scp?

share|improve this answer
Your first line is misleading to the point of spreading a bad myth. As @Javier pointed out in a separate Answer, AFP migrated to TCP in 1997, so it no longer has the MTU limitation that it had in the 80's and 90's when it could only use AppleTalk's Datagram Delivery Protocol (DDP was the AppleTalk protocol suite's Layer 3 equivalent to IP). It was AppleTalk DDP that had an MTU limitation of something like 900 bytes, so not exactly "very small", but certainly less efficient than Ethernet's 1500). – Spiff Mar 25 '10 at 20:25

For a long time now, AFP works over TCP, and it no longer meddles with packet size; or any packets in fact.

Nevertheless, i had an absurd experience with 3Com switches some years ago. It worked perfectly with windows and linux machines, with any kind of traffic i put there; but anything that involved a mac was stupidly slow (like 100kbits/sec or so). I called customer service and sent them lots of traffic captures; but as soon as they saw any packet that ethereal labelled as Apple...whatever, they said "we don't support appletalk" and closed the case. I managed to change the switch 3 times; but there was no difference.

needless to say, that was the last 3Com product i ever bought or recommended. Now i use DLink and Dell switches. no issues with those.

Of course, it's not your case.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.