On Wed, Jun 18, 2003 at 01:28:32PM +0200, Rogier Wolff wrote:
> On Wed, Jun 18, 2003 at 09:09:59PM +1000, Martin Pool wrote:
> > On 17 Jun 2003, Rogier Wolff <[EMAIL PROTECTED]> wrote:
> > >
> > > Oops. Missed one line in the last patch....
> >
> > Thankyou. That looks good.
> >
> > If we're going to make this more accurate it might be worthwhile to
> > actually look at how long we really did sleep for, and use that to
> > adjust time_to_sleep rather than resetting to zero.
> >
> > Also I'd prefer the variable be called micros_to_sleep or
> > us_to_sleep. Small point I know.
>
> OK. Agreed.
>
> If I'm going to do "gettimeofday" calls, I might just as well keep a
> variable that keeps the "time until we've used our quotum".
>
> Whenever we're ready to "sleep", we'll get the current time, and only
> sleep for the difference.
>
> The trouble is, that if we end up using 5 seconds worth of CPU time,
> we should not suddenly try to catch up for those whole 5 seconds....
Something on the order of:
us_to_sleep = max(us_to_sleep - us_since_last_write, 0);
us_to_sleep += amount_to_sleep_for_this_write;
> I like to set bwlimit to about 90% of my link capacity. This causes
> rsync not to fill the link: filling the link causes my provider to
> drop my packets. Also rsync won't fill my queues leading to higher
> latencies on interactive traffic.
>
> But if we allow bursting of those 5 seconds that we didn't have any
> data, we'll fill the link to the brim for 50 seconds! (if there
> suddenly is a nice supply of fresh data) This is undesirable. So, I'm
> still thinking on how to make this more accurate, but prevent big
> bursts. I'm considering not allowing more than bwlimit of
> backlog. (c.f. leaky bucket bandwidth limiting in the packet filtering
> world........)
It sounds like your problem is less that there are tiny
sleeps than that you have too many big transmissions.
Take a look at the "Smoother bandwidth limiting" thread.
Balancing these two issues for sleeps in the 10 to 100ms
range may be the best approach.
--
________________________________________________________________
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
