On 09/12/2007 10:23:31 AM, Josip Rodin wrote:
On Sun, Sep 09, 2007 at 07:16:12PM -0500, Karl O. Pinc wrote:
> Package: mirrors
> Severity: wishlist
> Tags: patch
>
> When mirroring from a fast mirror over a slow link
> anonftpsync can hog all the bandwith, to the detriment
> of more important tasks.
>
> Attached is a patch which uses the rsync --bwlimit
> option to address this problem.
The patch is fine, but I'm not sure if we want to actively support
people in
limiting the speed of incoming rsync, because that's usually an
indication
that they don't actually have the necessary bandwidth to be running a
mirror
in the first place.
I guess that's more a mirror policy question. (And as
far as policy goes there's always the debmirror package,
which is easily configured to do lots of rude things.)
The mirrors page does
not say that you should only mirror if you will make your mirror
public. I love my mirror because it speeds up my maintenance,
although it's probably not an overall bandwidth win it gives me
the gobs of bandwidth at the time I need it. I use the mirror
to "bank" bandwidth.
One reason why I want to limit bandwidth is because it's an
easy and straightforward way to keep high-latency away from
my VOIP traffic. I'm using a hierarchical fair service curve
quality of service algorithm so that I can have several
queues that "borrow" bandwidth from each other, but it can
take some seconds to adjust and in the meantime my phone calls
turn to crud. The only thing that really messes with the VIOP
are large, continuous, high-bandwidth transfers, which for
me almost always means anonftpsync. Sometimes I do want to
make a call in the middle of the night.
So, QOS issues is what I'd argue for. It's hard when you want
both low bandwidth low latency and high bandwidth high latency
on the same link, and don't have gobs of bandwidth to spare.
Karl <[EMAIL PROTECTED]>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
