Smoother bandwidth limiting

[jw schultz]

On Thu, Nov 06, 2003 at 06:08:28PM -0800, jw schultz wrote:
> I'm getting more and more convinced that --bwlimit should
> never have gotten into rsync.  Bandwidth management belongs
> at the system level or let it be done with a common
> networking utility instead of at the individual utilities.

There seems to be some strange idea floating around that i
am suggesting that --bwlimit should be removed.  Balderdash!

Once a feature gets in it stays in unless it is completely
broken such that no one uses it.  Even broken features don't
get removed without a super-majority and a major version
number bump.  This is why we have to be extremely careful
about allowing new features into the mainline tree.

> Why don't you see about getting it added to openssh.  That
> way it would be usable for more than just rsync.

If rsync didn't have --bwlimit i would be pushing people to
do it externally to rsync.  To me it seems the perfect thing
to add to ssh and i am sure there are utilities that can do
it for pipes and for network ports.  My point is that it
belongs in the infrastructure not the application or if done
in the application should be done using a plugin.  But
since rsync already has the feature it will stay.

> If it is going to be changed it should be completely redone.
> Use nanosleep() not the deprecated usleep() nor select() and
> scale the block size according to the size of bwlimit.
> 
> Special case hacks of --bwlimit get my no vote.

And there you have my main point.  A hack that causes
regressions like the one proposed is bad.  A fix that
reworks the code and makes it more generally useful by
eliminating existing bugs and limitations is good.

The current version of --bwlimit is bursty on lower limits
causing bandwidth overflow then dead time; and has a maximum
throughput dependant on the system clock (4Mbps at 100HZ).
A properly functional version would fix those problems and
would also incorporate buffering to improve throughput (see
archives).

PS.  With regards to the proposed patch I suspect that a
write size of 1368 would produce better network utilisation
than 1024.