v 7.6.22
Win-10
Einstein@home
Firstly, I had to open a new account when BOIC suddenly decided that I didn't exist, even though I have posted here before!
I am puzzled that during the E@h runs, what starts off as 12.5 hours, frequently becomes ~20+ in practice. My other BOINC project displays an accurate estimated run time.
Can anyone advise here?
Lawrence

That's generally a problem at projects that cannot accurately estimate before hand how long a given data set will compute, non-homogeneous, non-deterministic. The only thing you can do to get a quicker adjusting of the remaining time of started tasks is to create an app_config.xml for the project and add the <fraction_done_exact/> tag for the specific application.

---

Coelum Non Animum Mutant, Qui Trans Mare Currunt

Einstein runs old Boinc server software, it still uses 'Task duration correction factor', while other projects use 'Average processing rate',
There is only one DCF per project, so each each different application type from a project bumps the runtime up or down as DCF alters,
it can't be very accurate, not without a lot of project fiddling of the different task type's <rsc_fpops_est> values.

Claggy

WCG uses v7 server software on dont_use_dcf to stop clients from recomputing the buffer estimates, and its a mess for multiple variable runtime sciences, so they simply pass the returned result fpops averages back into the headers of new work.

We need dcf at app level... something asked for since years, to return the client side buffer estimation functionality.

---

Coelum Non Animum Mutant, Qui Trans Mare Currunt

Thanks everyone for that. I just wanted to know what was going on so I am grateful for the replies :-)

Lawrence

We need dcf at app level... something asked for since years, to return the client side buffer estimation functionality.

The Dev's said it couldn't or wouldn't be done, Jason G went and did an experimental Boinc 6.10.58 with it implemented, worked fine, Dev's still weren't interested.

Claggy

The development environment has changed with the governance struc. If that code could be revived, checked-in and pulled for a test build, that would be the greatest [and a function to disable the server instruction to <dont_use_dcf/> so members can opt to rely on the client estimator again]. I've always understood that tag as being a stop-gap to issues such as developed e.g. for Muscular Dystrophy where you could have 1 minute and 12 hour jobs coming out for the same app. For the extreme, a server side capping of 'In progress' was introduced, plus AFAIR, DCF up was slow and DCF down was fast. Current cap at WCG is 35 tasks per core, all sub-projects combined, so a client can never totally choke.

---

Coelum Non Animum Mutant, Qui Trans Mare Currunt