The estimate of Crunch Time is too high

I received the following query by PM.

My policy is not to respond to standard queries by PM - for two main reasons.

1) There is a huge 'education' opportunity being missed when responding by PM. I always take the view, supported by the large number of people who lurk on these boards, that it's the lurkers rather than the OP who stand to benefit most from a detailed response. I often get accused of being too verbose but that doesn't bother me. I'm targeting my response at people who perhaps know less than the OP or who may have closely related queries that they don't feel competent to pose.

2) There are a lot of good people who answer queries on these boards. Some are undoubtedly more competent to answer certain questions than I am. It's good to share the load of answering questions with all the other volunteers who choose to do so.

The quick answer to the question is to tell the OP that the problem is most likely a DCF (duration correction factor) that is out of whack. He has two choices.

A) He can let BOINC deal with it as BOINC will gradually move the DCF to a better value (at the rate of 10% of the difference amount for each fresh result that completes. It could take a week or two, depending on the speed of the machine and the number of cores.

B) He can stop BOINC and edit the state file (client_state.xml) to make the full adjustment by hand and then restart BOINC. If you are comfortable with editing .xml files, this is the way to go. If you make a mistake during editing you can easily lose your entire cache of work. This option is not recommended for people who are just donating computing resources and who wish to 'set and forget.'

The long answer (the one I would always try to give) is to go into some scenarios as to why the DCF might have got out of whack in the first place. If the Devs have got things in an 'optimal state', the DCF will be close to 1.0 and tasks will be taking pretty close to the estimate. With E@H there is a variability that is not easily predicted so the 'optimal state' is never going to be fully achieved. Also different platforms have different behaviours so whilst one host might truly have a DCF close to 1.0, others might need values of say 0.7 or lower or even up to 1.5 or higher, just to keep the estimated time close to the actual time. These variations would be quite normal.

The OP mentioned estimates that were wrong by a factor of 10 (actual time is only 10% of estimated time). This situation is never 'normal'. The DCF must be of the order of 10 rather than the hoped for value of around 1.0. A quick inspection of the state file, searching for the tag (in the Einstein project section of the state file - be careful if you have multiple projects) would soon confirm the diagnosis. If everything seems to stack up as expected, a quick fix would be to shift the decimal point one place to the left - that is reduce the value by a factor of 10.

Why would the DCF get so out of whack? I can immediately think of two possibilities and others may know of more.

1) A bad CPU benchmark run could severely miscalculate the CPU capabilities which would cause the DCF to be adjusted correspondingly upwards or downwards from the proper value.

2) A significant CMOS time adjustment being made while BOINC is running. In the middle of a run, imagine that the CMOS time was adjusted by a large amount because someone noticed a date error. When the task completed BOINC could be fooled into thinking that the runtime was vastly different to what it should have been and could make a corresponding large adjustment to DCF.

So if something like this may have happened, the appropriate action would be to set the DCF value back to what it should be, relying on one of the two approaches listed earlier.