Second Project Crowding Out Einstein@Home
16 Jun 2017 2:01:56 UTC
Topic 208317
(moderation:
Hi Everyone,
I'm just getting back into distributed computing after a long hiatus (I remember when Seti@Home was a standalone program 
). However, I've run into a bit of a problem.
I recently picked up a second @home project (for BOINC) . . . and its kind of crowding out Einstein@Home on my computer. This second project takes all the CPU time for itself, and relegates Einstein@Home to running solely on my GPU. . . even though they're both for the BOINC client.
Is there a way to prevent that? Seems like there should be a method to set the maximum amount of system resources each project can grab . . . but I'm not seeing such an option. Any suggestions would be greatly appreciated.
The beginning of wisdom would
)
The beginning of wisdom would require a change in your terminology. Projects don't grab system resources. Instead, the copy of BOINC running on your system decides what tasks to start, and the resource allocation mechanisms on your system (pieces of Windows 7 in your case) manage the contention among currently active tasks as to which running task runs on what resource when.
You get some votes in this game. You decide which projects you sign up for, and on each project, you may be able to specify which particular task types will be downloaded to your system. At Einstein this is quite fine-grained, managed from your user account page if you are logged into the Einstein web site, under Preferences|project.
You also convey an intention to BOINC as the relative proportion of your resources each project should get in the long term. The means it uses to do so are more than a little mysterious. But if BOINC keeps starting just one flavor, and not another, it might mean it thinks the "favored" project is behind in resource consumption and is trying to get it caught up. Another complication can be periods in which work of one kind or another is not available. After such a famine is relieved, the reaction can look unfair. Another complication can arise if BOINC believes you have deadline trouble. This leads to jobs believed at risk of failing to meet deadline jumping their place in queue.
I think the single most common user-avoidable cause of trouble is setting a work queue depth too high. How high is too high depends very much on the particular project, work, and characteristics of your system. Anything more than 0.1 day might cause trouble for some people sometimes. Over 1 day becomes much more likely to cause trouble, and over 5 days is practically guaranteed to give frequent troubling outcomes. The more BOINC task flavors appearing on your system, the more likely you are to get troubles avoidable by a shallower queue depth request.
A more direct intervention can be to disable work download from a specific project. A yet more drastic intervention is to suspend already downloaded, unstarted (or even started) tasks you'd prefer to run later.
Good luck.
Bryan_45 wrote:Is there a way
)
The answers to the two questions asked in the above snippet are (i) Yes, and (ii) Yes, there is, although as archae86 so eloquently points out, the second question should really say, "... system resources BOINC can grab" , since it is BOINC and NOT the project that makes these decisions :-). The individual project has no say in the matter and simply provides work when requested by BOINC.
I have contributed to a number of different projects in the past but essentially only to Einstein in more recent times so my thoughts on how BOINC handles this might be a bit out-of-touch with any 'improvements' that might have been made to more recent versions of BOINC to do with how BOINC handles sharing. Archae86 did mention 'resource share' which is an available BOINC setting. You should be able to find it quite easily in your project preferences. Follow the preferences link near the top of your account page. By default (unless you deliberately choose otherwise) each project will be given a value of 100 (which you can easily change if you decide to). Theoretically this supposedly gives each project an equal share of resources. It's a very complicated story but suffice to say, this 'ideal' has never really been achieved in even fairly simple cases and probably never will be.
So if you felt one project was missing out, just try increasing its resource share and making a corresponding reduction to the other (if you want to do easy mental arithmetic on the likely outcome). For example, assuming each of your current projects has a setting of 100, then each would have a share of 100/(100+100)=.5 or 50%. If you increased the first to 125 and decreased the other to 75, the first would get 125/(125+75)=5/8=62.5% and the other would get the remaining (in BOINC's view) 3/8 or 37.5%. By trial and error, I'm sure you could come up with two settings which would see both projects sharing the CPU resources better than what you currently have.
The probable reason you are having this difficulty is that GPU production is so good and the credit awards so high on Einstein that BOINC thinks you are getting far to much 'share' from that already. If your other project is CPU only, BOINC will probably be trying to even out the 'shares' by giving total preference to the other project's CPU tasks. By juggling the resource shares as mentioned above, you may be able to convince BOINC to let Einstein have a little bit of CPU work occasionally.
Another fairly easy way to let each project run CPU tasks in roughly equal proportions is to, every week, change the state of the 'allow new tasks/no new tasks function' in BOINC Manager, just for the other project. You wouldn't have to worry about stopping Einstein since, from your description, the other project being 'allowed' is going to do that anyway. If the other project is 'prevented', the work for it will finish and BOINC will happily source what it needs from Einstein until you reverse the setting again. If you keep a small work cache size as archae86 suggests, any remaining Einstein tasks at the time you switch to allow the other project will have no trouble just waiting for the week to pass until you again set no new tasks on the other project to allow Einstein to start crunching again. Even if you forgot to stop the other project after a week, BOINC would eventually use 'panic mode' to force the remaining Einstein tasks to be done before the deadline anyway.
If you wanted a 'set and forget' solution, you would experiment with resource shares until you found something appropriate. It could take a while. If you tend to 'see how things are going' fairly regularly, you might find it easier to reverse the BOINC Manager 'no new tasks/allow new tasks' setting once a week to give each project roughly equal time on CPU tasks. Happy micromanaging :-).
Cheers,
Gary.
Gary Roberts wrote:The
)
It's not the credit awarded by any project that causes this, it's Boincs own imaginary "Recent average credit" or REC.
When 2 projects are run on the same computer and one of them only has CPU applications and the other has both CPU and GPU applications then the GPU enabled project will run on the GPU and the CPU only project will most probably occupy all of the CPU cores.
Here's a link to the documentation on how Boincs scheduler works as of version 7.
And here's a link to another wiki on the subject.
Holmis wrote:It's not the
)
I was trying very hard not to go down that slippery slope :-).
As the documentation you linked to says, under the heading, "Proposal: credit-driven scheduling",
This is exactly why I made the comment, without mentioning RAC or REC or trying to explain the differences, that BOINC thinks the GPU project already has too high a share of the credit and is therefore trying to compensate by giving all the CPU work to the other project.
Of course, it goes on to discuss why we should use REC instead of RAC, but it does state,
Which projects grant credit 'fairly' and which ones don't is another can of worms I certainly wouldn't want to buy into. It would appear that the BOINC Devs are happy to penalise certain projects when the documentation suggests,
The reasons why people choose particular projects are quite varied. I don't really think it's the place of the Devs to interfere in that choice by designing a system to promote some and penalise others.
Most volunteers, myself included, have long ago given up any sort of expectation at all, that you can meaningfully assign a 'specific share' of your computers resources (or credit generating capacity, if you like) based on RAC, REC, or any other mechanism that may have been tried at various times in the past. My impression is that most people regard 'fair' as being a situation where all the projects they want to support get some work on a reasonably regular basis without huge 'floods' or huge 'droughts'. I'm pretty sure that most don't care about the intricate details - they just want a plan that looks like 'everybody gets a bit'.
Cheers,
Gary.