time variable throttling rsync traffic
c182driver1 at gideon.org
Mon Sep 14 12:07:16 MDT 2009
On Mon, 14 Sep 2009 13:09:41 -0400, Eric S. Johansson wrote:
> On 9/14/2009 9:25 AM, Andrew Gideon wrote:
>> So control is most effective at the sending rsync, which suggests that
>> bwlimit is a good approach. But the most information is available at
>> the receiving router, suggesting that shaping at the router is also a
>> good approach.
> Exactly what I meant by "suck in different ways including those we don't
> know yet". I think we have a couple of "low-cost options".
I don't think you're quite getting my point; I'm sorry I'm not being
clear. At the moment, I see *no* good option. I see a few different
partial solutions, but nothing that really (1) accurately controls the
flow while (2) taking other uses of bandwidth into account.
> As we
> discussed on the rsnapshot list, you could use the remote shell option
> to create a bandwidth limited remote shell.
I don't see how this is any better than the --bwlimit feature. It has
more control than what can be done at the router or server, but it
doesn't have the router's or server's awareness of the other uses of the
bandwidth. So while it can replace bwlimit, it cannot shape the traffic
in any intelligent way.
For example, if there are two, twenty, or two hundred rsync users, the
"bandwidth limited remote shell" wouldn't know to slow traffic down.
Or have I misunderstood you or missed something about the "bandwidth
limited remote shell" solution?
Even if the "bandwidth limited remote shell" were built to work with an
interceding server process to coordinate bandwidth use amongst rsync
users, this would still only be dealing with rsyncs to that server. It
ignores other servers on the same network, and it ignores other users of
the bandwidth in question.
I wonder: Is there something "smarter" than just withholding ACKs that
the receiving router (or server) could do to slow the incoming traffic?
More information about the rsync