On Fri, Jun 27, 2003 at 10:55:13PM -0700, Ben Escoto wrote: > >>>>> "jws" == jw schultz <[EMAIL PROTECTED]> > >>>>> 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: [EMAIL PROTECTED] Remember Cernan and Schmitt -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html