time variable throttling rsync traffic

[Matthias Schniedermeyer]

On 15.09.2009 12:11, Eric S. Johansson wrote:
> On 9/14/2009 3:55 PM, Andrew Gideon wrote:
>
>>> If there is one or more bottleneck link in the network (places where
>>> traffic feeds from one or more links with aggregate larger capacity
>>> into a link with smaller capacity) then it makes sense that this work
>>> has to be done on the router that is on the sending side of the
>>> bottleneck link(s), not on the receiving side.
>>
>> I've been assuming that this isn't possible for a couple of reasons.
>>
>> Since this is a remote backup application, I'm assuming that senders are
>> "all over".  That is, there is no one "sending router"; there are
>> instead many sending routers.  The only routers common to all these data
>> streams would be those close to the receiving server.
>>
>> Next, most random users have no control over their routing
>> infrastructure.
>
> run rsync till a given time deadline, killing off the original program 
> instance and then restart with a new bandwidth limit.  I would probably 
> use a small program invoking rsync and then sending a signal when "it's 
> Time" then starting a new rsync run.

I had a similar problem with "wget" some time ago, i needed a dynamic 
"limit-rate". What i did was patch in a "limite-rate-file"-option that 
changes the "limit-rate"-variable with the contents of the file whenever 
the mtime of the file changes. It even works when the file is missing 
initally (no initial "limit-rate" then)


Just an idea, it sucks in some ways but "Works for me(tm)".



Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.