[haiku-commits] Re: r35129 - haiku/trunk/src/kits/tracker
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Tue, 19 Jan 2010 02:10:07 +0100
On 2010-01-18 at 10:04:46 [+0100], Stephan Assmus <superstippi@xxxxxx> wrote:
> A lot of factors go into how long such an operation will take, not only how
> many files/folders need to be created versus how much data is going to be
> moving and on which devices. The access pattern of writing back delayed
> blocks seems to have the greatest impact in making the speed measurements
> instable.
That's what I thought.
> But even if you could take all that into account at the beginning
> of the operation, you don't know what the user may do in the future while
> the operation runs. Therefor, the numbers will always have to be adjusted
> during the operation.
No doubt.
> The current algorithm can certainly be improved, but
> it tries to average the speed from about a past 20 second time-window at
> any given time. The estimated finish time is a total average from when the
> operation started or from the last time the operation was unpaused. This
> isn't ideal, since when other factors begin to slow down the operation
> (possibly outside of Tracker's scope, like when you suddenly "svn stat"
> your tree on the same disk), the estimated finish time will constantly
> shift into the future. But that could even be considered ok, since there is
> a chance that the interfering operation will stop and the time will become
> stable again. Of course one could use a much bigger time window for the
> estimated finish time and disregard measurements from too long in the past.
> It would be easy to adjust the algorithm like that. However, to strive for
> completely accurate numbers is a waste of time, IMHO, since like I said,
> you cannot know what will happen during the operation anyway, so you have
> to work with some sort of time-window and make your estimate be based on
> that.
You misunderstood what I was saying. Averaging over 20s is good enough, I
guess. But until 20s after the initial caching effects end it will likely
produce too optimistic estimates. As a user I much prefer the initial
estimates to rather be on the conservative side.
CU, Ingo
Other related posts:
