time variable throttling rsync traffic
ms at citd.de
Tue Sep 15 10:55:08 MDT 2009
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
> 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)".
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.
More information about the rsync