Author 
Message 
DoESVolunteer tester
Send message
Joined: 11 Oct 08 Posts: 784 ID: 30382 Credit: 74,895,590 RAC: 0

2 weeks ago I posted my comments about "time to completion" and received some valued comments from the guru's about different cpu speeds etc and that the work units do not progress in a simple linear function However, doing a bit of maths in my head I could get a completion time that always seems fairly accurate. Being a curious sort of person I began logging task progress info into an excel sheet whenever I'm near the PC I'm yet to catch a WU in the first few minutes of progress. So far I've got data on Cul, PSP & 321. Using CPU time as a linear function of % complete at 5% to calc WU time you will get to within 1 hour accuracy at 52% complete you will have an error of only a few minutes. Remember I am using the data supplied by BOINC GUI and as the % indicator progresses in jumps I do expect a certain margin of error (also I'm not counting seconds)
My point is
1/  So far the WU's seem to progress in a very linear manner. (allowing for error margin at low %)
2/ From the threads I've seen it seems likely some members are aborting WU's because of excessive times stated by BOINC yet they could have done the WU in a reasonable time. This is not good for PG.
3/ I don't think the BOINC GUI has a bug To me It's just poor maths. I Ignore the Time to completion and work it out for myself.
4/ While I have not recorded data on all work units yet A simple linear algorithm based on CPU time as a function of % complete would be far more accurate than the current BOINC GUI.
5/ I ccurrently have a WU (Woodall) awaiting a start completion time 104 hrs Rubbish It will get done in 30+ hours.
6/ The high completion time does not worry me I am offended by the BOINC GUI completion time indicator increasing in time as the WU progresses then jumping back only to increase again. It can only claim some accuracy in the final moments.
DoES 


DoESVolunteer tester
Send message
Joined: 11 Oct 08 Posts: 784 ID: 30382 Credit: 74,895,590 RAC: 0

An added point to this post
I understand it would be virtually impossible to state an accurate completion time before a WU starts given the range of PC's That fine just try to get it somewhere near the mark AFTER the WU begins. 


RytisVolunteer moderator Project administrator
Send message
Joined: 22 Jun 05 Posts: 2651 ID: 1 Credit: 55,781,647 RAC: 134,429

The WUs progress is linear. BOINC manager shows weird completion times because of the initial estimate, which is hard to choose because of differences in different workunits. It is impossible to modify estimate in the runtime.
____________



DoESVolunteer tester
Send message
Joined: 11 Oct 08 Posts: 784 ID: 30382 Credit: 74,895,590 RAC: 0

Rytis
I fully understand about the initial estimates and the resultant weird time given. I am only interested about after the WU starts. I don't quite get what you are stating about runtime Once the WU starts the completion time does alter in a manner  it increases in time then reduces in an instant by some number of hours only to start increasing again This is what I am pointing out BOINC should be able after 10% to give a resonable accurate time to completion.
Onec a WU starts excel can do it I can even do it my head and get a rough calc
DoES 



Boinc does not give this estimate so quickly because some projects have non linear progress.
Boinc has been built to suit all projects.
____________




From BOINC code:
// Returns the estimated CPU time to completion (in seconds) of this task.
// Compute this as a weighted average of estimates based on
// 1) the workunit's flops count
// 2) the current reported CPU time and fraction done
//
double ACTIVE_TASK::est_cpu_time_to_completion() {
if (fraction_done >= 1) return 0;
double wu_est = result>estimated_cpu_time();
if (fraction_done <= 0) return wu_est;
double frac_est = (current_cpu_time / fraction_done)  current_cpu_time;
double fraction_left = 1fraction_done;
double x = fraction_done*frac_est + fraction_left*fraction_left*wu_est;
return x;
}
result>estimated_cpu_time() returns the initial estimate given by the project. fraction_done is the current progress, from 0.0 (0%) to 1.0 (100%). All CPU times measured in seconds.
Does anybody know why fraction_left is used squared in the final calculation? Maybe this is a bug, and the cause of wrong estimated remaining time?
(PS: ugh, why is the forum so broken? [code] doesn't keep indentation, [pre] shows extra blank lines)
____________
Try an alternative BOINC client!




Does anybody know why fraction_left is used squared in the final calculation? Maybe this is a bug, and the cause of wrong estimated remaining time?
Ok, I think it was actually correct... But that's *weird* code... Not designed to be understood by a human later.
____________
Try an alternative BOINC client!




6/ The high completion time does not worry me I am offended by the BOINC GUI completion time indicator increasing in time as the WU progresses then jumping back only to increase again. It can only claim some accuracy in the final moments.
Time increasing and then jumping back is because the science app isn't reporting progress every second, but CPU time does increase every second. A simple linear interpolation of current CPU time and progress percentage would do exactly the same.
____________
Try an alternative BOINC client!



DoESVolunteer tester
Send message
Joined: 11 Oct 08 Posts: 784 ID: 30382 Credit: 74,895,590 RAC: 0

Nicolas
When you observe the BOINC GUI
H M % To Comp  My Calc H M
5 31 22.65 39.25  CPU T / % *100 = 24 21
This WU was complete in 24H 34M  BOINC time is out by 15H
I have tested the calc at various times during a WU (5% to 80%)
 Yes it does jump around but only by a few minutes
I understand what you are saying If I was to repeatedly do this calc (every sec) I would also get increasing T to Complete dut to the stationary % BUT I would still be far more accurate than BOINC using the above calc.
When the % jumps there is a point of accuracy I have done a few calc's around this time and found them extremely accurate BOINC is still out by some hours.
I also understand that some BOINC WU's on other projects progress in a Log or Exp manner and linear calc's would not work. But looking at the BOINC community I'm not certain their calc works well on any Project WU.




From BOINC code:
// Returns the estimated CPU time to completion (in seconds) of this task.
// Compute this as a weighted average of estimates based on
// 1) the workunit's flops count
// 2) the current reported CPU time and fraction done
//
double ACTIVE_TASK::est_cpu_time_to_completion() {
if (fraction_done >= 1) return 0;
double wu_est = result>estimated_cpu_time();
if (fraction_done <= 0) return wu_est;
double frac_est = (current_cpu_time / fraction_done)  current_cpu_time;
double fraction_left = 1fraction_done;
double x = fraction_done*frac_est + fraction_left*fraction_left*wu_est;
return x;
}
result>estimated_cpu_time() returns the initial estimate given by the project. fraction_done is the current progress, from 0.0 (0%) to 1.0 (100%). All CPU times measured in seconds.
Does anybody know why fraction_left is used squared in the final calculation? Maybe this is a bug, and the cause of wrong estimated remaining time?
(PS: ugh, why is the forum so broken? [code] doesn't keep indentation, [pre] shows extra blank lines)
Here's my read of this, using my current PSP Sieve unit: Initial estimate was 3651 seconds. After 2400 seconds, the unit is 85.896% done.
The "time to completion" is a weighted average. 85.9% of it is composed of the realtime calculation: double frac_est = (current_cpu_time / fraction_done)  current_cpu_time; (2400/.85896  2400 = 394.08). If the unit was completely linear, it would be 8.68 more minutes.
The other 14.1% of it is composed by the initial estimate (14.1%*3651 = 514.94, and then that amount is given a 14.1% weight). Here's the code that does the weighting: double x = fraction_done*frac_est + fraction_left*fraction_left*wu_est; (.85896*394.08 + .14104*514.94 = 411.1 seconds.
At the time I took down those calculations, the listed TTC was 6:51, or 411 seconds.
The "problem" is a smooth linear transition between initial estimate and realtime calculation. Maybe it'd be better served to have a more aggressive transition, say before 25% use the initial, after 50% use realtime and transition between those two? 


DoESVolunteer tester
Send message
Joined: 11 Oct 08 Posts: 784 ID: 30382 Credit: 74,895,590 RAC: 0

Jon
__________________________________________________________
The "problem" is a smooth linear transition between initial estimate and realtime calculation. Maybe it'd be better served to have a more aggressive transition, say before 25% use the initial, after 50% use realtime and transition between those two?
__________________________________________________________
This is my point exactly It is very difficult to transition from an initial Completion Time that is out by some 60Hrs for the actual computer when the WU first starts Any transition calculation simply prolongs the error period Why do this??? Just send the WU with a time estimate (however wildly inaccurate) Don't use the given time estimate anywhere in the calculation at all!!! Use simple linear extrapolation and immediately substitute the given Comp Time with the new value.
The current system seems to do a "snapshot" calc every 1 minute or so (I havn't timed it) that increments the % Complete In my investigation I have recorded data of WU's as eary as 5, 11 & 15 min into operation Linear calc's at this very early stage will have a 3% to 10% error margin By the time you you get to 30min the error is less than 1% Rember that I have never recorded sec and all data is viewed then typed into Excel for calc's so I am adding to the error margin myself
My suggestion is to do a linear calc every 1 min and present the result as time to completion At 1 min lets assume a 50% error at 5min 10% error and so on  all WU's tested show minimal error after 1Hr of progress. BOINC will show up to 250% error after the WU starts 100% error after 50% completion and achieves accuracy in a logarithmic manner toward the very end of the WU.
Any method will have some margin of error (particularly in the very early stages) the linear calc achieves high accuracy very early in the WU's progress.



DoESVolunteer tester
Send message
Joined: 11 Oct 08 Posts: 784 ID: 30382 Credit: 74,895,590 RAC: 0

Jon
While I was posting the last thread I was thinking it would be possible to transition if you really had to by incorporating somthing like Y = Time^X in any formula It would not be easy to establish a derivative from variable data sets However "us poor ole Engineers" are often required to produce formulas from "organic" and varied data Sometimes the only way is to apply "hit & miss" formulas across a graphical representation and derive a formula that has an acceptable error margin. This might be the case here. 



Some projects are unable to report % done.
This is why they need the given estimate in place.
~Bob
____________


