|
On Thu, 3 May 2001, Alois Treindl wrote:
> But rsync uses either rsh or ssh as a 'transport protocol', and our
> rsync in the local machines is configured to use ssh, so we are
> back to the original question.
Rsync also has native rsync protocol. It is probably faster than rsh, but
not as safe as ssh, and (like all other rsync transports) supports
compression (-z).
> ssh is slow in the local network:
> for a 9.1 Mb gzipped file I measure 7 seconds.
>
> rcp takes less than 1 second.
>
> For transferring 10 Gb of data, this is about 7000 seconds (2 hours)
> versus 1000 seconds (18 minutes).
Let ssh/scp compress the data stream with -C rather than compressing the
stream before encrypting. You should see a pretty substantial increase in
performance of scp.
If you are using rsync, you hopefully aren't transferring a complete 10G
anyway, just the differences in the source and dest trees.
I don't see any reason why rcp wouldn't work, but I'm confused. Your
problem is bad performance of scp on local networks, so you are targeting
rcp as a director-managed service for non-local hosts? Over smaller WAN
links, the differences between rcp and scp in performance decrease as the
bottlneck is not the CPU encrypting and decrypting but the network.
thornton
|
