DCF by application

[MarkJ]

Currently BOINC (6.4.5) maintains DCF by project. Please enhance BOINC to maintain a seperate DCF for each app within a project.

Since Seti introduced a 2nd app (Astropulse) the calcs get totally confused as to estimated completion times and can cause BOINC to fetch too much work and run tasks in high priority. This is further compounded by the recent release of Seti's 3rd app (CUDA multi-beam).

When BOINC has the capability to process both CUDA and normal versions of tasks this will confuse thing even further. IE a Seti MB (gpu) will have different DCF to a Seti MB (cpu) on the same machine.

Einstein are gearing up for a release of their 2nd app (PALFA search) so this will impact them as well. They also have a CUDA app in the works.

[Nicolas]

I agree. But note David Anderson wrote in a different ticket:

DCF is a kludge to compensate for bad FLOP estimates by projects. I don't want to make the kludge even more complicated.

[Silverfish]

Prime Grid seems like a perfect example of a project where this might be useful. There are a number (11 at the moment) of different applications, which have the potential to need very different DCFs, or at least on my computer. Also, some of the longest work-units (such as my current Cullen Prime Search LLR) are predicted to take in the order of 230 hours, rather than a more realistic 50-60 hours, thus leading to unnecessary "panic mode".

My computer is a AMD Phemom 9500 Quadcore, with 4GB of Ram, by the way. My current DCF is 9.27, whereas the DCF for the Cullen Prime Search LLR should be about 2.2, if the above work unit is typical.

[davea]

Maintaining per-app-version DCF in the client isn't too hard, but that's only part of the job; DCF is also used by the scheduler to decide what jobs can be sent. For this, we'd also need to add to scheduler requests a list of app versions and their DCFs, and extend the scheduler to parse this and use the DCFs if present. I won't have time to do this until late Aug. or so.