Hello dear BOINC enthusiasts,

I’m currently only receiving work units from two projects, with these priorities:

- asteroids@home: 200
- World Community Grid: 20

Despite this, my client keeps receiving mostly WCG tasks, even when asteroids@home shows a large backlog of tasks ready to send (as it has for the past few days).

To get asteroids@home tasks again, I had to abort all the queued WCG tasks. But the next day, the queue filled up with WCG work units again.

Is asteroids@home’s priority handling not working correctly? Is WCG simply more aggressive in distributing tasks? Has anyone seen this behavior before or knows what might be causing it?

Thanks for any insight!

I found some answers on the general BOINC forums, it seems the resource share is long-term, and so since I've done a lot more work for asteroids, it "catches up" to get 20% of total CPU time by only doing the other project.

Here are related threads:
- how to prioritize one project over the others?
- Setting project priority manually?

Cheers!

Yes, this occurs because of the Boinc client REC (Recent Estimated Credit) algorithm that always runs in the client. The client tries to balance all your projects credits based on the average credits accrued across all your projects and resource shares.

In the case where one project has a long spell of work completed and credited, when another project starts getting work again, that project needs to 'repay the credit debt' owed to the other recently run project. This then appears to override the clients resource shares and runs the long dormant project exclusively for a while and this observation is commented on frequently by new crunchers that their resource shares are not being observed correctly.

There is one tweak the cruncher can use to ameliorate this effect with a cc_config.xml default option called <rec_half_life_days>10.000000</rec_half_life_days> in the file.
If you change the REC averaging period from the default ten days to a single day, the credit debt can be repaid much sooner and the client will return to observing your resource shares more closely much sooner.

So edit the cc_config.xml file for this parameter in the <options> section by changing it to <rec_half_life_days>1.000000</rec_half_life_days>

---

A proud member of the OFA (Old Farts Association)

Thanks so much Keith!

Do you know if there's any way to get the 'current results' of the algorithm? As in, the REC for each project?

Thanks so much Keith!

Do you know if there's any way to get the 'current results' of the algorithm? As in, the REC for each project?

No, not directly. The work_fetch_debug flag in the Event Log options can provide a clue to how much debt each project has to any other.
But the output is extremely large, detailed and hard to suss out one individual parameter in all the other junk it exposes.
Normally you only turn it on for just a couple of scheduler connections since it will swamp the log if left enabled.

The other logging flag that is useful is rr_simulation. It does something similar to work_fetch_debug but doesn't swamp the output as much. Between the two, if you dig into the output you can see somewhat the relation between projects and their priorities to getting and running work on the host.

I'd try rr_simuation first.

---

A proud member of the OFA (Old Farts Association)