Oops more testing was required....

jw schultz jw at pegasys.ws
Wed Jun 18 21:33:46 EST 2003


On Wed, Jun 18, 2003 at 01:52:10PM +0200, Rogier Wolff wrote:
> 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
> links.... 

Think about modem links that run at 1KB/sec or slower.  You
aren't just saying sleep at least 100ms, you are also saying
to pump enough data down the line to warrant a 100ms sleep
even if we are doing small writes.

> 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
> 10ms. 

False.  System clocks vary a by orders of magnitude.  Some
are as slow as 50 or 60hz (power line frequency),
2.4 linux on ia32 is indeed 100hz as are some proprietary
UNIXes but most newer platforms are currently running at
tick rates of 1000 or 1024hz with 4Khz and higher on the
horizon thanks to faster CPUs.

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

If you were talking about adding a knowledge of timer
resolution to the code i'd say OK.  But you are talking
about hard-coding logic on the false assumption of a fixed
clock rate.

The round-down effect is true of select where the timeout is
an upper bound and a not sleeping is permissable.  Perhaps
what we should be doing instead is nanosleep which
guarantees a sleep at least as long as requested unless a
signal is received and per POSIX can provide the actual time
slept.

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

Only if it actually knows the local clock rate.  Even then
you should be taking into account balancing so you don't
spend half seconds sleeping between overflowing the pipe.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt



More information about the rsync mailing list