Oops more testing was required....

jw schultz jw at pegasys.ws
Sat Jun 28 17:18:30 EST 2003

On Fri, Jun 27, 2003 at 10:55:13PM -0700, Ben Escoto wrote:
> >>>>> "jws" == jw schultz <jw at pegasys.ws>
> >>>>> wrote the following on Fri, 27 Jun 2003 19:49:22 -0700
>   jws> Long term, i think the bwlimit stuff needs a complete
>   jws> reexamination.  In addition to the sleeping times and spreading
>   jws> the load as in the "smoother bandwidth limiting" but also its
>   jws> converse, Craig's buffering.  I suspect the approach is to have
>   jws> a network write routine that deals with buffering, write
>   jws> splitting and sleeping in a coordinated way.
> Do you think it is necessary for rsync to have to have bandwidth
> control at all?  It seems this should be someone else's
> responsibility.  For instance, if rsync is run over a pipe, something
> like cstream or throttle could be used (I don't know if these are
> really suitable, but there's no reason a separate utility couldn't do
> it).  Even for the daemon, maybe it could be run over some bandwidth
> limiting proxy or something, if the OS couldn't limit the bandwidth
> directly.

The idea of application level bwlimit seems attractive but
is probably misplaced from a design perspective.  The two
reasons i can see for bandwidth limiting are to prevent
rsync from saturating the network or link to the detriment
of other activity and to prevent route oversaturation (the
cause of this particular thread).  The latter is really the
responsibility of the router or routing layer.   The former
too is likely best managed in the network stack or router.
That said, for many OSs there is not sufficient QOS to rely
on it at level.

If there is such a need one wonders why it is that ssh
doesn't have such an option.

	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt

More information about the rsync mailing list