Wrong remaining time

Grzegorz Skoczylas
Grzegorz Skoczylas
Joined: 18 Jan 05
Posts: 2
Credit: 11870066
RAC: 10618
Topic 229437

This is not a serious bug. More like a small ... quirk.

If it took one hour and 11 minutes to calculate 24% of the sample, how would it still take more than 7 days to calculate the remaining 76%? A simple calculation in memory shows that it should only take about 3-4 hours more to calculate the remainder of the sample.

mikey
mikey
Joined: 22 Jan 05
Posts: 12640
Credit: 1839026161
RAC: 5485

Grzegorz Skoczylas

Grzegorz Skoczylas wrote:

This is not a serious bug. More like a small ... quirk.

If it took one hour and 11 minutes to calculate 24% of the sample, how would it still take more than 7 days to calculate the remaining 76%? A simple calculation in memory shows that it should only take about 3-4 hours more to calculate the remainder of the sample.

Short answer is its not perfectly linear

long answer is it can take 10 valid tasks for the Project to know how long a task will take on your pc so it's just a guesstimate. Then if you switch tasks that 10 tasks thing starts over for the new tasks.

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5870
Credit: 116961111640
RAC: 36810731

Grzegorz Skoczylas wrote:If

Grzegorz Skoczylas wrote:
If it took one hour and 11 minutes to calculate 24% of the sample, how would it still take more than 7 days to calculate the remaining 76%?

Of course, it won't :-). This probably just means that the completion time for a previous task on that particular machine was extraordinarily long and this caused BOINC to set a new, ridiculously long estimate.

Over time with quite a few completed tasks with the correct completion time, BOINC will decrease the estimate to something much more reasonable.  If you are comfortable editing BOINC's state file, you could fix it much more quickly.  There is always a danger of corrupting the state file so it's safer to wait for BOINC to do it for you.

You have 3 computers attached to the project.  If you specify which particular computer had that task, it might be possible to see what had disturbed BOINC's estimate for how long tasks should take.  Part of the problem is that there is a single "duration correction factor" used for all E@H searches so the problem may not be associated with the task/search that was running when you first noticed it.

With multiple searches on the same machine, you will always see the estimates moving up and down somewhat, depending on whether estimates are currently high or low, but not to the extent that a few hours suddenly becomes many days.  The task you showed must have started with an estimate of higher than 10 days to be still over 7 days at this point.

It seems impossible for a previous task to have taken that long since BOINC would have canceled the task with a "Time Limit Exceeded" error message long before that.  In fact, this machine already has a number of such errors for FGRPB1G tasks.  Perhaps it is not suitable for the FGRPB1G search.  Those errors don't change the estimate for other tasks though.

For the example you showed, it seems likely that something happened to completely distort BOINC's elapsed time value for some earlier task.  For example, was the date/time for that machine adjusted dramatically while BOINC was running?  It seems likely that the discrepancy was local to the computer and not a problem or bug with the project software.

Cheers,
Gary.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.