If after 30 minutes it's at 10%, the estimated time to completion would be 10 times the time already taken (i.e. 5 hours) and keep climbing until it hits 20%

That is the estimated time to completion used in v 4.45. If we have completed FRAQ of the work, where FRAC is between 0 and 1, then expected total time is CPU / FRAC and the time left is CPU * ( 1 - FRAC ) / FRAC .

Another way to estimate time to completion is to go simply by the original estimate of the time, so time left would be ORIG * ( 1 - FRAC )

The first totally ignores the original estimate, the second totally ignores the information gained fro the run time so far. Version 5.2.x combines the two so that it moves smoothly from the second estimate at the outset to the first estimate at the end.

In the case of Rosetta this means that time drops at each new %complete value, and then rises again but more slowly than it was rising before, and more slowly than the estimate in v 4.45

If after 30 minutes it's at 10%, the estimated time to completion would be 10 times the time already taken (i.e. 5 hours) and keep climbing until it hits 20%

That is the estimated time to completion used in v 4.45. If we have completed FRAQ of the work, where FRAC is between 0 and 1, then expected total time is CPU / FRAC and the time left is CPU * ( 1 - FRAC ) / FRAC .

Another way to estimate time to completion is to go simply by the original estimate of the time, so time left would be ORIG * ( 1 - FRAC )

The first totally ignores the original estimate, the second totally ignores the information gained fro the run time so far. Version 5.2.x combines the two so that it moves smoothly from the second estimate at the outset to the first estimate at the end.

In the case of Rosetta this means that time drops at each new %complete value, and then rises again but more slowly than it was rising before, and more slowly than the estimate in v 4.45

So if the BOINC devs wanted to avoid the rising 'time to completion' altogether, what about this algorithm: start with ORIG-CPU, then update ORIG with CPU/FRAC each time a FRAC jump occures ?

If after 30 minutes it's at 10%, the estimated time to completion would be 10 times the time already taken (i.e. 5 hours) and keep climbing until it hits 20%

That is the estimated time to completion used in v 4.45. If we have completed FRAQ of the work, where FRAC is between 0 and 1, then expected total time is CPU / FRAC and the time left is CPU * ( 1 - FRAC ) / FRAC .

Another way to estimate time to completion is to go simply by the original estimate of the time, so time left would be ORIG * ( 1 - FRAC )

The first totally ignores the original estimate, the second totally ignores the information gained fro the run time so far. Version 5.2.x combines the two so that it moves smoothly from the second estimate at the outset to the first estimate at the end.

In the case of Rosetta this means that time drops at each new %complete value, and then rises again but more slowly than it was rising before, and more slowly than the estimate in v 4.45

So if the BOINC devs wanted to avoid the rising 'time to completion' altogether, what about this algorithm: start with ORIG-CPU, then update ORIG with CPU/FRAC each time a FRAC jump occures ?

That would mean the manager would have to remember previous values - at present it has no stored values and at each update it recalculates everything from data supplied by the RPC. Not a problem if it had been designed differently in the first place.

In short it would be a bigger redesign than might be regarded as sensible when the proper fix is for Rosetta to recalculate the fraction more often. Infrequent updates of the frac and infrequent checkpointing are understandable in a prototype app, but should not be a long term feature of any app, in my opinion.

River~~