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.
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.
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?
Just a hunch but it's quick to test. Try doing this on both Macs:
...note what it reports. It'll be an integer, probably the value 2 or 3...then set it to zero:
...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.
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.
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?