Smoother bandwidth limiting

wolf b.wolf at hzd.hessen.de
Fri Nov 7 22:03:32 EST 2003


Its just another vote for bwlimit

Since bwlimit was introduced with rsync 2.4.x  it is doing for me its 
job very well and was for me a very good enhancement of rsync.

thank you.

>I rather like bwlimit... i suffer the same problem as Mikko in that I have a slow uplink.  I haven't experienced his particular problem, though, and bwlimit seems to do its job well...
>
>Using some other networking tool or QOS just complicates the matter, and since rsync excels at doing large transfers over slow connections, bwlimit seems within the scope of rsync...
>
>So it's not perfect, nothing is...  RSYNC would loose a lot of appeal if bwlimit got axed, at least for me...
>
>Make that a Yay vote from me...
>
>*********** REPLY SEPARATOR  ***********
>
>On 11/6/2003 at 6:08 PM jw schultz wrote:
>
>  
>
>>This again?  Where 1024 was arbitrary not magic.  This would
>>reduce the maximum throughput on a 100HZ system to
>>~100KB/sec no matter what the --bwlimit value is.
>>
>>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.
>>
>>Why don't you see about getting it added to openssh.  That
>>way it would be usable for more than just rsync.
>>
>>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.
>>
>>On Tue, Feb 04, 2003 at 03:06:05AM +0200, Mikko Rauhala wrote:
>>    
>>
>>>Hello
>>>
>>>I'm using a cable modem with a slow uplink, and therefore when I want to
>>>transfer large amounts of data upstream, I tend to use rsync with
>>>--bwlimit. However, the stock rsync seems to send a bit too much data at
>>>once for comfort, momentarily blocking my meager upstream enough to
>>>bother latency and downstream data transfer (through not getting through
>>>enough ack packets when rsync data fills the cabel modem buffer).
>>>
>>>I tried a quick kludge, simply limiting the size of a single write()
>>>operation so that the write/sleep cycle happens more often, yielding (I
>>>hoped) a more steady flow of data, so that the cabel modem buffer
>>>wouldn't contain too much data at any point. Through comparing
>>>interactive session use before and after the patch, I would have to
>>>conclude that this kludge worked in my Debian GNU/Linux (unstable) box.
>>>
>>>Now, the point is that I like the kludge and I'd like rsync proper to
>>>adopt perhaps a lesser-kludgeish command line option (or something) for
>>>this kind of functionality, if you're so inclined. Might be useful to
>>>others in similiar circumstances.
>>>
>>>Here's my quick kludge (just a one-liner really, thanks to a proper
>>>write loop structure), which probably can reduce performance in the
>>>general case through using more writes, but has worked nicely for me
>>>(against 2.5.5 from Debian's sources; and yes, the "1024" is a magic
>>>number):
>>>
>>>--- io.c.old    2002-03-22 07:14:44.000000000 +0200
>>>+++ io.c        2003-02-04 02:50:14.000000000 +0200
>>>@@ -440,7 +440,7 @@
>>>                if (FD_ISSET(fd, &w_fds)) {
>>>                        int ret;
>>>                        size_t n = len-total;
>>>-                       ret = write(fd,buf+total,n);
>>>+                       ret = write(fd,buf+total,(n<1024?n:1024));
>>>  
>>>                        if (ret == -1 && errno == EINTR) {
>>>                                continue;
>>>
>>>-- 
>>>Mikko Rauhala   - mjr at iki.fi     - <URL:http://www.iki.fi/mjr/>
>>>Transhumanist   - WTA member     - <URL:http://www.transhumanism.org/>
>>>Singularitarian - SIAI supporter - <URL:http://www.singinst.org/>
>>>
>>>      
>>>
>>
>>    
>>
>>>-- 
>>>To unsubscribe or change options:
>>>      
>>>
>>http://lists.samba.org/mailman/listinfo/rsync
>>    
>>
>>>Before posting, read:
>>>      
>>>
>>http://www.tuxedo.org/~esr/faqs/smart-questions.html
>>
>>    
>>
>>>-- 
>>>To unsubscribe or change options:
>>>      
>>>
>>http://lists.samba.org/mailman/listinfo/rsync
>>    
>>
>>>Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
>>>      
>>>
>>-- 
>>________________________________________________________________
>>	J.W. Schultz            Pegasystems Technologies
>>	email address:		jw at pegasys.ws
>>
>>		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
>>    
>>
>
>
>/\/\/\/\/\/\ Nothing is foolproof to a talented fool. /\/\/\/\/\/\
>
>coreyfro at coreyfro.com
>http://www.coreyfro.com/
>http://stats.distributed.net/rc5-64/psearch.php3?st=coreyfro
>ICQ : 3168059
>
>-----BEGIN GEEK CODE BLOCK-----
>GCS !d--(+) s: a- C++++$ UL++>++++ P+ L++>++++ E- W+++$ N++ o? K? w++++$>+++++$ O---- !M--- V- PS+++ PE++(--) Y+ PGP- t--- 5(+) !X- R(+) !tv b-(+) Dl++(++++) D++ G++(-) e>+++ h++(---) r++>+$ y++**>$ H++++ n---(----) p? !au w+ v- 3+>++ j- G'''' B--- u+++*** f* Quake++++>+++++$
>------END GEEK CODE BLOCK------
>
>Home of Geek Code - http://www.geekcode.com/
>The Geek Code Decoder Page - http://www.ebb.org/ungeek//
>
>  
>





More information about the rsync mailing list