Sharing Among Projects
20 May 2021 14:15:19 UTC
Topic 225432
(moderation:
It appears that behavior has changed since MilkyWay@home came back online. Before their outage I had two projects, MW@Home and Einstein@Home. They seemed to share my computer reasonably. I was collecting credits daily for both projects. I would see a mix of Einstein and MilkyWay tasks. There would be up to 8 total, reasonable on my 8 Core i7 running Linux, all BOINC parameters at default values. When an 8 CPU MW n-body simulation started, all the others would go into "waiting to run" status until the simulation finished.
Now it's different since MW@Home came back. I see 8 Einstein tasks and 8 MW tasks. The Einstein tasks never seem to get any CPU time. When the MW 8 CPU n-body simulation runs, everything else waits. When the simulation finishes, only the MW tasks, usually 7 separation runs, seem to advance. This happens until one of the MW tasks completes, then another 8 CPU n-body simulation comes along to make the cycle repeat again.
Meanwhile, it has been days since I collected any Einstein credits derived from tasks I've run. I think I got a few credits from someone else verifying a run a made earlier. I don't think the Einstein tasks are running.
Is their some way to make sharing more equitable again? I really want to share my computer equitably between the two projects.
TIA
To a certain extent, BOINC is
)
To a certain extent, BOINC is trying to 'pay back' MilkyWay for the time lost while the server was offline. Old hands may remember the concept of 'debt' from early versions of BOINC: that's now been replaced by something called 'REC', but the principle is the same.
REC will sort out your problem automatically over time, but it's a slow process - the excess REC built up while Einstein had sole access to your machine will decay over a half-life of 10 days. If you're into fiddling with configuration files, you can speed that up, but it's probably not important enough to bother.
I don't know why REC is
)
I don't know why REC is default set to 10 days. I always change it to 1 day.
Seems that if that was the default, we wouldn't see so many messages about the REC "debt" problem.
It would be resolved in a day and nobody would notice a problem and make the posts.
Thanks! This reminds me of
)
Thanks! This reminds me of the old *nix "Fairness" scheduling algorithm. Tasks that hadn't run in a long time got a priority boost so they'd get at least "some" time. I claimed at the time it should not have been named "Fairness," that "Pity" was more accurate. Also, at that time I was working for Wind River Systems as a VxWorks FAE. The idea of a system changing task priority assigned by the system designer by itself was correctly viewed as heresy in the real-time world where a late answer was a wrong answer. The only time a scheduler could give a priority boost by itself was to avoid priority inversion deadlock. The semaphore mechanism that enabled priority inversion prevention was well documented. I spent quite a while in every training class I gave about how that worked and why.