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.... 
> 
> 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........)

I'd suggest experimentation with shaping your own traffic.
lartc.org looks like it has some good stuff on it
particularly wondershaper.

Long term, i think the bwlimit stuff needs a complete
reexamination.  In addition to the sleeping times and
spreading the load as in the "smoother bandwidth limiting"
but also its converse, Craig's buffering.  I suspect the
approach is to have a network write routine that deals with
buffering, write splitting and sleeping in a coordinated
way.