Wayne replied to my original note which said that in a special situation that I was 
using to probe rsync to build a behavioral model that bwlimit= resulted in bimodal 
behavior around a 4000 kbyte/sec value.

He responded with a patch that I have tested in a limited way. I have a push scenario 
from a local site to a remote site. I use a file that is 6.3 Megabyte in size whose 
checksums (when written to batch) are 60k bytes and whose deltas (when written to 
batch) are 40k. I touch the local file (but do no modifications to the file other than 
changing its modification time) and then rsync the file with the command string

"time rsync -ar --rsh=rsh --bwlimit=<x> foo.tar remote://test" where foo.tar is in the 
local directory /test. I have recorded the "real" , "user", and "sys" values to get an 
idea of the shape of the curve as I vary <x>. I have values for <x> of 8000, 4000, 
2000, 1000, 500, 250, 175, 100, 50, 25, 12, 6, 3, 2, 1. The resulting curve for lower 
values of <x> is a near linear line. At the upper end the "real" value is a constant. 
There is a knee to the curve between 500 and 100 for this particular file size.

I have done nothing to validate that the peak transmission rate is accurate. It is not 
important to my original goal. 

I would like to express my appreciation to Wayne for the patch. It allows me to do my 
work.

I have tested the patch against a large file (9.2 Gigabytes) that results in a 
checksum file of 3.5Meg and a delta file of 2.3Meg and used a bwlimit=1 and tested the 
"real" time against an expected "real" time and got a comparable result. My expected 
completion time was 96 seconds based upon 5.8 Meg total traffic and the measured time 
was 114 seconds. There is only 20 seconds unaccounted for, so the bw throttling may 
not be 100% on the money but I dont think it is off that much. My intuition is that a 
large part of the 20 seconds is idle time in the communications pipe caused by 
processing and scheduling delays, etc. 

Wayne's patch is better than the previous implementation. 

Wayne's patch insures that the "average" transmission rate will not exceed the bwlimit 
and my partial testing seems to validate that. 
It does not enforce that the instantaneous transmission rate will not exceed the 
bwlimit. 

In my case, I am more interested in what the total network between the local and the 
remote system will allow so Wayne's patch meets my needs. It may not be exactly 
accurate but it is close enough for me to create my models.

bwlimit is not main line functionality. It is useful for doing things like I am doing, 
but how much effort should we put into it?? When rsync is doing what it was designed 
to do, we need it to run as fast as the network will allow it to run?? Or, is there 
value in throttling it during normal operation? How accurate does the throttle have to 
be?

wally

PS - If there is interest in the data I am collecting for my model, I am willing to 
share that data when I have completed the testing. It will be targeted for my needs 
(thus incomplete for some others) and it will be based upon the hardware and OS 
environment of my servers and not necessarily of any value on others. 
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Reply via email to