I have a general question concerning how BOINC manager (6.12.33) displays the time to completion for running tasks. I'm not sure if this is related to BOINC manager, or the specific WU's, so I thought I'd start here. :-)

I've noticed that the time to completion on longer tasks - 10 hours or more - increases as the task is running. This doesn't affect all tasks from all projects, it seems to be random. And, I haven't sat down and looked very closely too see which projects or task this occurs on. And before I forget, the estimated completion time does go down when the task is waiting to run, but then begins counting up again when processing.

I do understand one important word regarding the time to complete - estimated. Out of curiosity, is what I'm seeing something that needs to be corrected, or should I just sit back, go back to sleep, and enjoy crunching numbers for science?

For some tasks from some projects the completion time will count up when the task is running. Don't worry about it. I've never seen completion time change when a task is suspended. Are you sure about that? You should ask about that at the appropriate project as that's their "problem" not BOINC's problem.

I didn't think it was anything to lose sleep over, just had to ask - the devil made me do it! :-)

To clarify one point with the completion time changing while suspended, maybe I didn't state what I was seeing correctly. I didn't mean while the task is suspended, but when it is 'waiting to run'. And the time doesn't change while waiting, it's just... different?

For example, I receive a WU with a 30 hour estimated completion time. I have the default swap time between tasks set at 60 minutes. So, this WU starts running, but, the time to complete counts UP, not down. At the end of it's allotted 60 minute time slot it shows 31 hours remaining, with 1 hour elapsed, for a total of 32 hours for the 30 hour WU.

Now, it gets placed in the 'waiting' queue, where it shows 29 hours remaining with 1 hour elapsed, for a total of 30 hours for a 10 hour WU. That's what I would expect to see.

When it gets processor time again, it once again shows the remaining time counting up instead of down. At the end of the second processing run, it shows 30 hours remaining, 2 hours elapsed, for a total of 32 hours again. When it ends up in the waiting queue this time, it show 2 hours elapsed, 28 hours remaining, for a total of 30 hours again.

It continues counting the remaining time the wrong way until some threshold is reached, which, unfortunately, I haven't been able to see while it's happening. I beleive it's somewhere around 8 to 12 hours or thereabouts. I've noticed this behavior on long WU's from Docking, QMC, SETI Astropulse, Einstein, etc. It's happened on several WU's from several projects, on several platforms.

I have a couple of old computers (the dinosaurs) running BM 6.6.8, which don't show this behavior, while the newer computers, running BM 6.12.33 do. because of that, I thought it might be related to something in BOINC Manager.

i hope that cleared things up a little.

I found the increasing time remaining to be very annoying as well on my Boinc 6.12.34 (x86). I understand the time remaining is an estimate, but at some point something should be able to improve on the original estimate based on the actually task progress made. If a task begins with a 3hr remaining time estimate to complete at 0% progress, but runs for an elapsed time of 15hrs and is showing the task is only 25% progress completed shouldn't it be obvious that a better estimate to complete the remaining 75% of the task should be estimated around an additional 45hrs? Instead Boinc may show an estimate to complete around 3-6 hrs that is still incrementally increasing a few seconds at a time. Despite realizing the slow progress, its difficult not to look at that 3-6 hr time remaining while comparing that time to your other tasks and forgetting that that particular tasks estimate is off by at least a factor of 6. Perhaps this bad estimate also affects Boinc's ability to properly prioritize its tasks as well?

In windows file manager you get a time estimate when copying a large quantity of files from one drive to another. If something affects that initial time estimate, like beginning another large task you may see that initial estimate immediately double. The time estimate may again reduce in time if progress starts improving again. These moving estimates are far better at any point in time than any estimate that gradually increases second by second and really gives you no actual idea of the time remaining for the task.

---

BOINC doesn't work with time estimates, simply said it does calculate the remaining time from a combination of estimated resource fpops (floating point operations, an integer value, not a time slice) plus the task duration correction factor plus the benchmarks of your CPU. BOINC will learn by adjusting the TDCF how long tasks of the same project and application take. But since there's only one TDCF per project, not per application, projects with multiple applications will see fluctuating estimate end times.

The amount of fpops on the task is giving you the initial estimated time as it is done by a hypothetical machine. Since no computer out there is exactly the same as another, it's not possible to work with anything else than fpops. Even seemingly two identical machines can run the same task to different run times, just because of something about the machine or its environment.

Don't pin yourself on the end time, as you noticed it's an estimate. From start to finish will it be an estimate, and the progress bar isn't going to help here. There are tasks that come in with an estimate of 150 hours or more, but that run in 5 hours or less. There are tasks that run from 0% to 90-95% in the first minute and sit on that last amount for hours upon end, before ending at 100%. There are tasks that run to 100% before resetting to 0% and doing another run to 100%. There are tasks that run to 100% and then continue to do calculations for an extra 5 minutes or more.

---