I'm currently running BOINC 7.6.22(x64) but this problem goes back to the scheduler rewrite a while back.

I'm running Seti (resource share 250), Einstein (RS 2), and 3 other projects with resource share 50. I have not run Einstein for a very long time but it remains in my project list. Since Seti does not currently have a GPU version on 1/16 I decided to enable Einstein.

Since 1/19, my computer has not run a single Seti task.

I've seen this before. Whenever I enable Einstein, it completely takes over my machine and almost nothing else runs. I've tried medium resource shares for Einstein, I've tried a share of 1 and 2, and everything give this same result: almost nothing else runs. This is why I gave up running Einstein.

I think there is a scheduler problem here that should be fixed.

---

Even with the present form of the scheduler, BOINC still uses a form of debt between projects. You have told BOINC it shouldn't run Einstein for a long time, but when you allow it it asks for a full cache of work, because it's been so long since you last ran it.

If you now do absolutely nothing, you will see that while Einstein may take over for a while, eventually -when its debt towards Seti and the other eligible projects has diminished- Einstein will let go and only ask for work once in a blue moon.

The resource share on its own does not dictate how much work a project can ask for, not until all eligible projects have run for a while and BOINC knows what's what. So initially even on an RS of 2 you will get a full cache of work, just as much as you've set the work request for, but if you let that sit for several weeks or months, you will see that BOINC learns and eventually not take up as much work anymore.

One thing to keep in mind:
Changing resource share is a long term process, it's not instant.
With each change you make to the RS of a project, you reset things BOINC learned earlier about this project's RS needs and run times. So just don't.

---

Even with the present form of the scheduler, BOINC still uses a form of debt between projects.

What's the debt formula? Is it based on RAC or total credit? Credit granted per project is wildly different and not useful in inter-project debt calculations.

I would love debt calculation based only on total CPU/GPU time used without regards to credit.

The resource share on its own does not dictate how much work a project can ask for, not until all eligible projects have run for a while and BOINC knows what's what. So initially even on an RS of 2 you will get a full cache of work, just as much as you've set the work request for, but if you let that sit for several weeks or months, you will see that BOINC learns and eventually not take up as much work anymore.

I guess it had a purpose when a rival project to SETI came on sceen but with multi projects now Resource share is useless for I doubt any user will wait for several weeks or months before BOINC learns to share resources.

What's the debt formula? Is it based on RAC or total credit? Credit granted per project is wildly different and not useful in inter-project debt calculations.

It's based on RAC.

---

My Detailed BOINC Stats

What's the debt formula? Is it based on RAC or total credit? Credit granted per project is wildly different and not useful in inter-project debt calculations.

It's based on RAC.

No, it's based on REC (Recent Estimated Credit) - project inflation is excluded.

Estimated Credit

That paper suggests a delay rate (half life) for REC of 1 month: in the end, a default of 10 days was chosen, but that's configurable.

What I dream of is an interface of vertical sliders, one assigned for each project enrolled on the client.


The sliders always add up to 100% usage of available processing cores. A user can drag a slider up and down to give dominance to a particular project while the other projects then automatically get adjusted while maintaining their current relative levels to each other. A button can push pushed above slider to lock it in place while adjusting the others. Another button can control whether the project is accepting work and a third for suspending the project and a horizontal slide can adjust how many cores a project is allowed (app_config setting <project_max_concurrent> knowledge known). The slider system would be confined to the subset defined by the global preferences of core and CPU slice percentages.

This method would be quick, intuitive and give us complete control over how our resources (cores and CPU slices) are shared amongst projects and it would be an attractive addition to the basic interface. By experimenting with various levels we can optimize our RAC for the projects to our liking.

Credit per project varies from 0.0001 per second of CPU time all the way up to 0.3000 per second on the same machine (I've done fairly extensive spreadsheet study over 33 different projects) and so letting the client attempt to equalize credit over the various projects doesn't really work. It doesn't understand the games some of the projects play in attempting to dominate client resources with higher than typical credit, ignoring the daily limits on work d/led, switching to priority ignoring JAVA code or shortened deadlines. We can not deny that all projects are in competition for the cruncher's machine resources and some will use the credit system to get their benefit of completing their work. Until the day comes when the BOINC client has elevated AI and regular data on credit granted per project per app within each project, it's best to give people in charge of their computers best methods of controlling the usage of the processing equipment.

What's the debt formula? Is it based on RAC or total credit? Credit granted per project is wildly different and not useful in inter-project debt calculations.

It's based on RAC.

No, it's based on REC (Recent Estimated Credit) - project inflation is excluded.

Estimated Credit

That paper suggests a delay rate (half life) for REC of 1 month: in the end, a default of 10 days was chosen, but that's configurable.

So what would be the effect of these two settings:

1) Leaving <zero_debt>n</zero_debt> set to 1 on every start (deprecated in version 7 so it does nothing now?)

2) <rec_half_life_days>n</rec_half_life_days> set to 0 days. Would this mean the debt system would always go by current credit or ignore credit altogether and go only by resource setting?