Oops more testing was required....

[jw schultz]

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 <R.E.Wolff at BitWizard.nl> 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:		jw at pegasys.ws

		Remember Cernan and Schmitt