.. when it is transfering a large file it sticks around 11 mb/s.
without knowning, you could've caused a partial transfer when comparing transfer rates, making the CPU a bottleneck.
Rsync does a delta-transfer by default if it sees a partial file on the receiver (leftover from the
scp test?). The "rolling checksum" method of comparing what needs to be transfered will take its toll in CPU usage on the Sender side.
I noticed a 4-fold decrease in transfer rate on a large partial binary file with a weakish CPU as Sender (Intel Atom or smaller VM cloud instances). On bigger machines the transfer rate stayed up after the initial partial file scan when continuing. The difference in throughput to plain
netcat then should be the encryption via ssh.
Explicitly telling rsync to not to use partial transfers (
-W|--whole-file) will put transfer rates in the same ballpark again. If needed,
--append is another way to resume an interrupted file transfer without causing a delta-transfer.
get -a in
sftp can resume a download too.
See Rsyncs architecture description for further explanation.