Oops more testing was required....

Rogier Wolff R.E.Wolff at BitWizard.nl
Wed Jun 18 21:52:10 EST 2003

On Wed, Jun 18, 2003 at 04:26:48AM -0700, jw schultz 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.
> That would have to be a platform specific thing since not
> all systems modify the timeout value to reflect the amount
> of time not slept.  Nevertheless that is a nice idea.

no, no.  

Martin was suggesting to measure the elapsed time using gettimeofday.

> > Also I'd prefer the variable be called micros_to_sleep or
> > us_to_sleep.  Small point I know.
> I'm not too keen on forcing the minimum sleep to be 100ms.
> That is just too coarse for my taste and tends produce
> fits-and-starts stalling on very slow links.

100ms is a tenth of a second on both slow links as well as on fast

As Unix works with a system clock that increments only once per 10ms,
the system has to round a requested time up to the next multiple of

So if you request a sleep of 2 ms, we can round that to 10ms. Now if
current time is 100.1 jiffies (1001ms), the wakeup could be scheduled
at 101 jiffies (1010 ms). However, when the request to sleep for 2ms
comes in at 100.9 jiffies (1009ms), the wakeup at 1010 ms (101
jiffies) is too early. So we have to add one more to be sure to wait
AT LEAST the requested amount of time.

My rsync was doing 70 byte writes, limited to 30k per second, leads to
a sleep time of 2500 us. This is effectively rounded by the kernel to
20ms. So we're off by a factor of 8. 

I chose 100ms to make this rounding less than about 10%. 

When limited to 30k per second, I saw my rsync write chunks of 16k.
It then calculates a sleeptime of over 500ms, and sleeps that much 
in one go. So there you have your coarse time-resolution......

> This should be balanced with the "Smoother bandwidth limiting"
> thread.  Perhaps setting a minimum sleep to 10ms or
> a period based on the value of bwlimit.

No, the kernel rounding is time-based. Thus a time related heuristic
works best.


** R.E.Wolff at BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* The Worlds Ecosystem is a stable system. Stable systems may experience *
* excursions from the stable situation. We are currently in such an      * 
* excursion: The stable situation does not include humans. ***************

More information about the rsync mailing list