REC-based scheduler

History Lesson

For generations, the work scheduler in the BOINC client has been giving users headaches and them complaining to the developers, as the thing would hardly follow their preferences. This wasn't so weird, as there were many variables that the scheduler had to work with. Plus as BOINC versions progressed and GPU capabilities were added, it became clear that the present scheduler, with now CPU and GPU code included, was completely outgrowing itself.

As such, for BOINC 7, the scheduler has been rewritten from the ground up, and split into one for the CPU and one for the GPU. This will mean that you new BOINC has to relearn all about those pesky tasks, but if you leave it alone and don't micromanage things, it'll take 10 tasks per project application to get back on track.

Comments in the field

As explained by LadyL on the Seti forums:

REC = recent estimated credit

This is only relevant if you run more than one project.

What the client does is, it keeps a record of how much CPU/GPU time a certain project has recently seen. This translates into the REC. It compares this figure with the project share that has been set. A project that has worked less than its share will get priority in both scheduling (running tasks) and work fetch. Then as it gets crunch time its REC increases and another project will get to the head of the queue. Over time you get a more or less good distribution of crunching time according to resource share.

Points to note: GPUs are very productive so lead to high REC. If you run GPU projects along CPU ones on similar shares the GPU project sees virtually no CPU. CPU and GPU are scheduled separately. SETI will probably stay pretty high up in the queue, since getting tasks is hit and miss Setting a small 'additional days' cache will help getting tasks from seti, since BOINC will ask more often, thereby increasing your chances.

Original source http://boinc.berkeley.edu/trac/wiki/ClientSchedOctTen