BOINC / boinc

Open-source software for volunteer computing and grid computing.
https://boinc.berkeley.edu
GNU Lesser General Public License v3.0
1.99k stars 444 forks source link

DCF by application #789

Closed romw closed 7 years ago

romw commented 9 years ago

Reported by MarkJ on 7 Apr 38992832 13:46 UTC 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.

Migrated-From: http://boinc.berkeley.edu/trac/ticket/812

romw commented 9 years ago

Commented by Nicolas on 5 May 38992878 06:40 UTC 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.

romw commented 9 years ago

Commented by Silverfish on 26 Nov 39515392 17:46 UTC 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.

romw commented 9 years ago

Commented by davea on 18 Sep 39520723 18:40 UTC 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.

ChristianBeer commented 7 years ago

DCF was dropped and each app_version now has some statistics that enhance runtime estimation.