your problem is that you are testing too many things at once:
- disk read speed
- SSH encryption
- wireless
- SSH decryption
- disk write speed
Since you mentioned SSH I am going to assume this is a unix system...
You can rule out any problems with disk read speed with a simple
dd if=yourfile of=/dev/null #or
pv yourfile > /dev/null
on the receiving end you can do a simple disk write test
dd if=/dev/zero of=testfile bs=1M count=2000 # or
dd if=/dev/zero bs=1M count=2000 | pv > testfile
dd is not really a "benchmark" but since scp uses sequential IO, it is close enough
you can also test SSH by doing something like
dd if=/dev/zero bs=1M count=100 | ssh server dd of=/dev/null # or
dd if=/dev/zero bs=1M count=100 | pv | ssh server dd of=/dev/null
finally, to rule out SSH being the bottleneck, you can use nc to test the network performance
server$ nc -l 1234 > /dev/null
client$ dd if=/dev/zero bs=1M count=100 | pv | nc server 1234 # or
client$ dd if=/dev/zero bs=1M count=100 | nc server 1234
if you really want to properly test the network, install and use something like iperf, but nc is a good start.
I'd start with the nc test as that will rule out the most things. You should also definitely run the tests while not using wireless. 802.11n can easily max out a 100mbit port, but only if you have it properly setup.
(Ubuntu >= 12.04 defaults to netcat-openbsd. nc -l -p 1234 > /dev/null may be what you want if you're using netcat-traditional).
The first thing I would do is do a trace route from the new clients to the problem Xserve. If that looks normal, try mounting the share on the xserver using ciffs:// instead of afp:// or smb://.
You could also attempt to force your new Macs to run at 100mbps/duplex. If the network connection was flakey it could be doing odd things to transfers.
Best Answer
Get a better access point. You're taking huge bandwidth penalties because the link from the source machine to the access point is sharing bandwidth with the link from the destination machine to the access point. Better access points can handle multiple simultaneous streams. This not only immediately doubles the available bandwidth but it also reduces the number of changes in a stream's transmit direction.
Right now, to send a packet results in roughly the following:
The source machine obtains access to the channel, sends a preamble, and then sends the data to the access point.
The AP sends a preamble and then sends the data to its destination.
The destination obtains access to the channel, sends a preamble, and then sends the acknowledgement to the access point.
The AP sends a preamble and then sends the acknowledgement to the source machine.
All four of these operations are competing for the same bandwidth. Tweaks like disabling 802.11b support can help a bit.
If your 130Mbps link is degrading to 65Mbps or so due to link distance or your channel is shared with anything else (other Wifi systems, Bluetooth), your speed numbers are, unfortunately, about right for a bottom-of-the-line 802.11n access point with no compatibility options disabled.
While product recommendations are off-topic here, you can get WRT610Ns and E3000s refurbished for $60 or less. I've used dozens of them in both home and commercial deployments, all refurbished, and they've all worked like champs. This will give you 5GHz support too, which is generally wide open and performs better (though at shorter distances), assuming any of your endpoints support it. (I prefer the E3000 because it only exists in one hardware version, so I know exactly what I'm going to get.)