On Fri 21 May 2004, Wallace Matthews wrote: > Since --bwlimit depends upon sleep(1 second), I repeated the experiment with a file > that was 383 Megabyte so that when I am running unthrottled it takes significantly > longer than a second (ie. ~50 seconds) to complete. I get the same bi-modal behavior > but with different values for 4000 and 4001 respectively. The fact that the break > point stays fixed isnt intuitive (to me at least).
There have been earlier discussions about the --bwlimit behaviour, and that it's not that well suited for e.g. slower ADSL lines because it's rather "bursty", a limit of 20 means it'll write out at full throttle until it reaches the 20k, then it sleeps. There's an alternative --bwlimit patch that was posted back then, that takes a subtlely different approach (by also limiting the size of the writes). This prompted a discussion of whether this may have impact on the tcp packets going out on the wire, perhaps leading to extra tcp overhead which is contrary to rsync's goal of reducing network traffic at all costs... In the most recent Debian versions I've made the other bwlimit implementation available (via --bwlimit-mod, for "modified"). Of course, both ends need the Debian hacked version. My private tests have shown it to work pretty well, other people have also been happy. I haven't tried it with larger limits than about 100, though... I doubt whether it will have any effect on your test case. The patch was basically this: --- rsync-2.6.2.orig/io.c +++ rsync-2.6.2/io.c @@ -814,6 +814,8 @@ if (FD_ISSET(fd, &w_fds)) { int ret; size_t n = len-total; + if (bwlimit && n > (unsigned)(bwlimit*100)) + n = bwlimit*100; ret = write(fd,buf+total,n); if (ret < 0) { Paul Slootman -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html