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 andyparkins@xxxxxxxxx - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html