Smoother bandwidth limiting

[Martin Pool]

On  4 Feb 2003, jw schultz <jw at pegasys.ws> wrote:

> Yes but i'd like to hear from some people who know network
> performance programming.

I know only enough to be mildly dangerous.  :-)

I don't think you can do this optimally in userspace, because there is
lots of buffering between what we write to the kernel and what gets
onto the wire, which is generally what the user cares about.  

It will interact with the MTU, which is generally small enough not to
matter, but also with the TCP window size.  I think by throttling our
connection we will also change the TCP window dynamic behaviour.  

In particular with no bwlimit rsync will often be blocked on network
IO, but it may not be with bwlimit.  This might make a difference to
whether the Nagle algorithm comes in to effect to get packets pushed
out.

There is also some kind of interaction with routers with their own
queues (as for ADSL, etc), and performance on fast networks may be
very different.  So I would be a bit cautious of applying patches
based on one person's experience.

Doing larger writes is likely to make the bandwidth more "jerky", as
the kernel buffer is filled up, drains, and then pauses.  That might
make rsync's interaction with interactive traffic more harmful than it
ought to be.  But bringing it right down to 1024B doesn't sound good
-- it's likely to generate <MTU packets, which nobody really wants.

So by all means tweak it, but I think trying to make it run at the
exact specified limit is unlikely to pay off.

-- 
Martin