rsync speed on slow wireless links
matt at mattmccutchen.net
Mon Dec 14 00:23:26 MST 2009
On Thu, 2009-12-10 at 13:08 +0700, Max Arnold wrote:
> I've noticed that rsync performs significantly worse than wget on slow congested wireless
> links (GPRS in my case). I don't have large statistics, but in my tests rsync often stalls
> for 3-5 minutes, while wget stalls only for several seconds and then continues download.
> Is there any rsync protocol features which are sensitive to packet loss and unpredictable delay?
> I understand that rsync transaction has additional metadata transfer in the beginning (file
> list etc.), but after that what can affect the speed? Are there additional handshakes or
> flow control other than tcp ones?
> rsync -rtmz --partial --progress --delete-delay --delay-updates --stats --itemize-changes
> --timeout 120 --contimeout 20 source.example.com::module/file.zip /tmp/
Rsync isn't doing anything fancy that would cause it to be especially
affected by packet loss or delay. The protocol takes a few round trips
to set up, and then it is largely pipelined, so rsync can tolerate some
amount of latency without slowing down the whole process.
I can't explain why rsync would stall much longer than wget. The only
thought I had is that the network might have a quality-of-service policy
that favors port 80.
More information about the rsync