[rdiff-backup-users] ?long fat network: Poor Restoration Performance (Dean Cording)

[Steve . Dutky]

Dean,
I think you correctly attribute your problem to network latency.

You may wish to see 
http://en.wikipedia.org/wiki/Bandwidth-delay_product
for a quick summary, and, if you have root access on both sides, 
http://fasterdata.es.net/TCP-tuning/linux.html for possible improvements.

<dc><snip>
Restoring 6GB
of data took over 12 hours.  I'm located in Australia and my backups are
hosted on Amazon Web Services on the east coast of the US (can't get much more
offsite than that!). 

Investigations showed that neither the CPUs on either end nor the network link
were the limiting factor.  In fact, I was able to run three simultaneous
restore sessions with no degraded performance before the network link became
saturated.

This suggests that network latency (typically 250ms in my case) is the
determinate factor for the restore performance.  Whilst I don't know much
about the details of the protocol, it might be possible to speed up rdiff-
backup by using larger blocks or windowing.
</dc>

Thanks, Steve Dutky