Have been running 4.7.2, then 5.2.5, for a long time, so the Duration Correction Factors have had plenty of time to adjust, and seem quite accurate. The estimated times while a result is "ready to run" seem very close to reality, on all my hosts. However, once a result starts running, the "to completion" times become random and meaningless. Example from this very instant on my slowest Mac (old G3 iBook):

rosetta cpu time 7:14 progress 66.67% to completion 9:48
seti cpu time 7:15 progress 50% to completion 12:22

If the Rosetta WU is 2/3 done after 7 hours, it is unlikely to take another 9 hours to do the last 1/3.

If the SETI WU is half done after 7 hours, it is VERY unlikely to take 12 hours to do the other half.

In 4.72 the "to completion" times while running were "off" from the previously-pretty-good 4.4.3/4.4.5 times, but not by THIS much! (Example, from a Mac still running 4.72:
Rosetta cpu time 4:59 progress 90% to completion 0:57 - shouldn't take _quite_ an hour, but that's a lot closer...)

Edit:: I had a complaint about 4.4.x's "to completion" times because they "jumped around" too much - this has obviously been solved - but the solution went too far the other way, now they don't adjust enough...

---

OK, I've been playing with the algorithms in a spreadsheet, and I see the problem, I think - the contribution from the "actual speed" (time taken x percent completed) is used weighted by the fraction completed, when it should be weighted by the fraction completed SQUARED.

The current method appears to be:

(((fraction_remaining*original_estimate/100)*fraction_remaining)   [contribution from 'original']
+ ((fraction_remaining*calculated/100)*fraction_completed))         [contribution from 'actual']
/ 100

I believe it SHOULD be:

(((fraction_remaining*original_estimate/100)*fraction_remaining)   [contribution from 'original']
+ ((fraction_remaining*calculated/100)*fraction_completed^2))      [contribution from 'actual']
/ (100 + fraction_completed^2)

The difference in displayed "to completion" times, given an original estimate of 600 minutes, but with an actual run-time of 100 minutes:

      original calc   current corrected
at 0% 600      n/a      600      600
1%    594      99       589      583
10%   540      90       495      288
25%   450      75       356      111
50%   300      50       175       54
75%   150      25        56       25
90%    60      10        15       10

If a result is at 50% after 50 minutes, the corrected value of 54 minutes remaining is definitely better than the current value shown of 175.

Please note that all my work was done in "minutes" just because it makes the numbers much smaller - the code I'm sure works on seconds. The "/100" is because I used integer values for percentages, ie; 10% = 10 not 0.1, in order to have the squared value correct. Also, I didn't download the source and look at it - I'm identifying the 'current method' based on what I've seen, not on actually looking. Some developer want to look at this and see if I've got it right?

---

This continues to be an issue for people. It's now been brought up on MANY of the project's boards. Even on Einstein, which has the most-stable WU length... you can imagine how bad this is on Rosetta, with variation in length of up to 8-10x. Can we at least get acknowledgment that someone recognizes this as a bug?

---

David checked in a fix for this on the 2nd.

This fix has been included in 5.2.7.

---

----- Rom
BOINC Development Team, U.C. Berkeley
My Blog