rsync - Mar 2006 - sctp support for rsync?

Hi there

I've just done some brief reading up on SCTP, and I get the impression
it will allow multiple "threads" of streamed data as part of one
connection? I was wondering what impact that would have on high
bandwidth, high latency links?

Currently our bottleneck in using rsync is due to that. We have fat
pipes and yet a single rsync session cannot saturate it due to the
latency. I'm wondering if SCTP could help? (I'm guessing it would as
running multiple copies of rsync in parallel also "fixes" our problem)

-- 
Cheers

Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +64 3 9635 377 Fax: +64 3 9635 417
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1

On Mon, Mar 06, 2006 at 09:22:04AM +1300, Jason Haar
wrote:
> We have fat pipes and yet a single rsync session cannot saturate it
> due to the latency.
Rsync is not adversely affected by high latency connections because the
three processes (generator, sender, and receiver) all run concurrently
without waiting for any round-trip confirmations (until the end of the
entire file list).  If your link isn't being saturated, it should be due
to some other bottleneck, such as disk I/O, CPU, or just not being able
to rapidly find the files that need to be updated.

If disk I/O is the limiting factor, try using --whole-file (i.e. as
your transfer speed approaches/exceeds your disk I/O speed, rsync's
incremental update algorithm can take longer to find the differences
than it would take to just send the updated file).

It also helps to avoid things that laden the CPU, such as the --compress
(-z) option, and slow ssh encryption.  You can try switching ssh to
blowfish encrypt, or perhaps switch from ssh to rsh if CPU is your
limiting factor.

..wayne..