AFP painfully slow

Question

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

Solution 1

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.

Solution 2

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.

Comments

[Spiff]

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).

[user3873602]

This worked, thanks! btw is there a benefit in delaying acks?

[Spiff]

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.

[adib]

This doesn't work. Now what?

[Spiff]

@adib, why don't you ask a new Question with the details of your particular problem?

[deweydb]

Odly enough, these steps made the situation about 4times worse. from 11 minutes to transfer a large file, to 45 minutes.

[Spiff]

@deweydb, why don't you ask a new Question with the details of your particular problem?