question about --bwlimit=

[Paul Slootman]

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