Subject: Re: What's in git.git (stable)

From: Andy Parkins <[email-masked]>
Date: Thu, 14 Dec 2006 12:00:41 +0000

On Thursday 2006 December 14 11:27, Johannes Schindelin wrote:

> And now you know one of the reasons we have no true progress bar.
>
> Another reason is that it would be relatively expensive to calculate,
> since the total _size_ is not known beforehand (remember, the pack is
> calculated on the fly).

Hmmm; just thinking out loud now... I used to calculate ETA's for simulations 
I ran that had similar problems - i.e. you don't know how long it takes until 
its done (it was with genetic programming function trees, and of course you 
don't know what operations will be in the next generations tree, so you can't 
estimate a time).  I just showed "something" by doing a standard: how long 
did n/N take therefore N will take... then I plotted the error in the ETA 
after the simulation completed.  Interestingly it was always a -exp(-x) 
shape.  In other words it got more accurate towards the end (of course); 
which is exactly the sort of accuracy you would want.  At the beginning you 
just want a broad "this will take a few hours" measure.  Towards the end, you 
want to know "there is 1m50s remaining".

I wonder if the number of objects is a reasonable measure of progress.  Let's 
say we're transferring 100,000 objects.  Let's also say that the average size 
of objects is 100 bytes.  Let's finally say that the object sizes are evenly 
distributed throughout the 100,000 objects.  This would mean that the first 
1,000 objects are just as representative as the last 1,000 objects; or any 
other randomly chosen 1,000 objects.  In which case, the size of the first 
thousand objects would be approximately one hundredth the size of the total 
transfer.  Volia: an estimate of the total size of the transfer.

Obviously this estimate would be continuously updated, and would become more 
accurate as more objects are transferred.  The data rate would of course be 
based on only the previous X objects rather than the total transferred to 
take account of changing server conditions.  From these ETA could be 
estimated.

Obviously the ETA is unstable, but it's only for giving users an idea of how 
long is left; not for strict accounting.

Andy
-- 
Dr Andy Parkins, M Eng (hons), MIEE