So, today, here is an update of what this WU shows:
CPU TIME: 16:46, Progress: 26.78%, To Completion: 18:02
The completion has gone up every time I look at it!

That is to be expected as boincmgr will update the expected completion time based on the time it has already taken to do the amount of work it has.

The formula is something like:

    frac_est = (current_cpu_time / fraction_done) - current_cpu_time
    fraction_left = 1-fraction_done
    fraction_done*frac_est + (fraction_left * (fraction_left * wu_est))

This means that the total hours cannot be easily calculated as it depends on how long a particular fraction has taken to run against where it is in the percentage of WU

Yes - there are actually a lot of advantages to doing this. We have been working with David Anderson and BOINC to get this capability added. David has done a lot of work on this already and the folks at Superlink@Technion! are the first BOINC project to put the new code into production. We will be updating our servers to utilize the new code later this year.

Once we have the code, the server will assess the 'effective power' of the computer requesting work and try to send it work that won't take it more than a day or so. Effective power is the raw power of the computer * the amount of time that BOINC is allowed to run work on the computer.

Once we have tested this and feel good about it, we will modify how we create workunits so that there is a lot of variation in the size and computers will be able to get the appropriate size of work. This will reduce load on our servers as we will be able to send bigger workunits to those powerful always on computers and it will improve our ability to effectively use those computers that are less powerful and are only on infrequently (and thus have a hard time completing work currently).

So it is a definite advantage to do this and we are anxious to get this in place.

The BOINC benchmark is really a sorry piece of code running for most entirely inside the CPU without actually considering other real-life factors that influence computing such as memory and disk i/o. Another consideration is for example that I run 80% throttle (in this heat), but the benchmark runs at 100%. Some crunch part time as well.

Real flops computed and time needed are the probable main parms to build client historical performance statistics which will continuously adjust, based on new incoming results.

Further to my earlier post in the FA@H Single Redundancy Change thread, the longer of the 2 WUs that my A64X2 was crunching aborted about 1 hr ago, with the complaint in C:\Program Files\BOINC\stdoutdae.txt:
"01-Aug-2008 14:47:25 [World Community Grid] Aborting task - faah5010_1htg_1bwb_01_0: exceeded CPU time limit 158923.039707".
This was the longest WU that I have encountered since joining WCG in late 06. When I last looked about 11 hrs ago, BOINC tasks tab showed its percentage progressing OK at 32hrs CPU time, 56% complete. Now showing "Computation error". The WU in the other CPU stream, faah5010_1hvh_1gnn_00_0, finished normally after 39h52m.
This may have been a real error, but perhaps the CPU time limit is too small for these Experiment 24 WUs. If it was the time limit, expect a lot of other crunchers with slower machines to be a bit unhappy about losing credit for d-a-y-s of CPU time.