What a mess, who would have thought that! My estimated CPU runtimes also increased, but running a ~1 day cache setting this luckily didn't trigger panic mode of my BOINC.
I just which BOINC would set, treat and schedule things per ressource rather than per project / app. It's imposible to have one result duration correction factor apply to all co-/processors at once..
MrS
Here, here. The problem of multiple DCFs has been with us for many years, and an experimental version exists (and has been in use for almost as long), which tracks DCF at the 'per application' level, rather than 'per project'. However, this proposal wasn't accepted by the core BOINC development crew.
Instead, the BOINC developers preferred to move the Job Runtime Estimation server-side: it works, after a fashion, once that database of averages has been fully populated, but it's slow (too slow) to react to change, and it's fiendishly difficult to get right first time when a new app_version is started up from scratch. I don't think Einstein as a project has adopted the new system yet (although I know they've considered it - too much customisation, like the Locality Scheduling, in the current server code to allow an easy transition). Until that's been overcome, we're stuck with the single DCF for the Einstein project as a whole.
RE: What a mess, who would
)
Here, here. The problem of multiple DCFs has been with us for many years, and an experimental version exists (and has been in use for almost as long), which tracks DCF at the 'per application' level, rather than 'per project'. However, this proposal wasn't accepted by the core BOINC development crew.
Instead, the BOINC developers preferred to move the Job Runtime Estimation server-side: it works, after a fashion, once that database of averages has been fully populated, but it's slow (too slow) to react to change, and it's fiendishly difficult to get right first time when a new app_version is started up from scratch. I don't think Einstein as a project has adopted the new system yet (although I know they've considered it - too much customisation, like the Locality Scheduling, in the current server code to allow an easy transition). Until that's been overcome, we're stuck with the single DCF for the Einstein project as a whole.
RE: I don't think Einstein
)
It's being tested on the beta project Albert@home but I have a feeling it might take some time before it's implemented here.