I subscribe to 3 projects under BOINC with Resource Share levels indicated - Climateprediction.net (10%), SETI@home (80%), Einstein@Home (10%). My issue is that Einstein@Home effectively hogs the CPU and consumes way more than the 10% I assigned to it. In fact based on the Desdline dates under the Tasks display it seems to completely ignore the 10% and requests deadlines that make it the number one priority and consumes more like 80-90% of the CPU allocation.

Is this a problem with BOINC RS or something Einstein is not complying with? I have been trying to control it somewhat by stopping new work being requested from Einstein for a few weeks and then letting some more in before stopping it again.

I am running BOINC on Windows Server 2012 R2 on a HP Z420 Workstation.

I thought I would ask the question to see if there is something I did wrong before abandoning the Einstein project.

---

Jim Marshall
<a href="http://allprojectstats.com/showuser.php?id=78553"><img src="http://allprojectstats.com/su78553x4-2a10-1-0.png" border=0>

Reading that more often but eventually the project will have used up its block share and then fetching is supposed to stop and the next project will get its turn

---

Coelum Non Animum Mutant, Qui Trans Mare Currunt

I run all three of those projects, and a few more besides. I don't have any problems with resource shares, and I don't honestly believe that Einstein is deliberately doing anything to provoke this sort of behaviour. Instead, there are a number of factors which all interplay with each other.

First, both CPDN and SETI have very relaxed deadlines, unusually so - Einstein's deadlines are more typical of BOINC projects in general.

Second, SETI has a reputation for frequent outages, and people who run SETI have a tendency to request the maximum possible cache size - I don't know if this applies to you.

And third, SETI has the busiest servers in the business - they are frequently unable to supply work at the precise second it is requested, even though work would have been available a couple of seconds earlier or a couple of seconds later. Einstein, by contrast, almost always has work available on demand - they are one of the most reliable projects.

When BOINC decides that it's time to fetch more work, the relative availability of work does tend to skew the mix towards Einstein: BOINC will quite often request SETI work, receive none, and immediately request Einstein work instead.

But that doesn't explain the urgent running of the tasks received. That's a combination of cache sizes, deadlines, and the fraction of the time that BOINC is running. So: Einstein deadlines are 14 days, and you want them to run at 10%. That means that they have to fit 33.6 hours of running into that fortnight: if there is ever more than 33.6 hours on Einstein work in the cache, you're in deadline trouble. If your cache settings total more than that, I suggest you turn them down to say 1 day maximum, and see if that fares any better.

Richard, excellent explanation of the denial of crunch attack one project can inflict on others. If a project admin wanted to craft the size of workunits and deadlines to favor his project over others it is possible under BOINC. While the debit system is supposed to level this out, it is based on the assumption that all projects have work available all the time.

<ed>And we must not forget that RAC isn't a good measure of anything.

---

Great explanation - thank you. You are correct that Einstein, while not breaking any rules is probably using the deadline parameters to their best advantage which SETI is certainly not doing. I currently have a 5 day work queue and will try reducing it to 3 or 4 days and see if that helps level things out.