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):Just how magic is the 1024? To what was bwlimit set? And the MTU? You do bring up an interesting point. I could see restricting the write to bwlimit/100. Sleeping much longer than 100ms is a bit crude. something like max_xmit = bwlimit / 100; if (max_xmit < 1024) max_xmit = 1024; and then in writefd_unbuffered size_t n = len - total; if (max_xmit && n > max_xmit) n = max_xmit; I'm no network internals sorcerer (networking seems something of a black art) and wouldn't want things to get too magical but perhaps linking this into MTU or somewhat. I'd hate to see us setting it to a value that causes lots of padded packets.> > --- 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@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-- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.ws Remember Cernan and Schmitt
On Mon, Feb 03, 2003, jw schultz wrote:> Just how magic is the 1024? To what was bwlimit set? And > the MTU?The 1024 is very magic, I just pulled it out of my hat and 'lo, it worked well enough so I didn't touch it. I've usually used bwlimits of 4-12 depending on the time of day (expected available bandwidth in the neighbourhood) and my other traffic. MTU is 1500, but I'm not certain if the cable modem splits packages into smaller pieces than that for forwarding. I suspect not, though.> You do bring up an interesting point. I could see > restricting the write to bwlimit/100. Sleeping much longer > than 100ms is a bit crude.Tying the maximum amount to write to bwlimit sounds like a workable, a bit more general idea. -- Mikko Rauhala - mjr@iki.fi - <URL:http://www.iki.fi/mjr/> Transhumanist - WTA member - <URL:http://www.transhumanism.org/> Singularitarian - SIAI supporter - <URL:http://www.singinst.org/> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.samba.org/archive/rsync/attachments/20030204/fe622024/attachment.bin
Skipped content of type multipart/signed-------------- next part -------------- -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
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@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@pegasys.ws Remember Cernan and Schmitt
> 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...I had some of these issues initially when using --bwlimit. I since switched to true traffic shaping with CBQ. It works flawlessly as that is it's job. Max