I have 3 projects running and would like to set the project priority manually, is that possible at all? Since I have two cores I'd like to have one project running all the time and the other two sharing the remaining core 50/50.

I have 3 projects running and would like to set the project priority manually, is that possible at all? Since I have two cores I'd like to have one project running all the time and the other two sharing the remaining core 50/50.

Your resource shares, expressed as a percentage control how it divides its time. If you set your favorite project to 50% and the other two to 25% each that should achieve it.

---

MarkJ

Okay thanks, the reason I couldn't find anything regarding this was because I searched for priority instead of resources... :)

I have 3 projects running and would like to set the project priority manually, is that possible at all? Since I have two cores I'd like to have one project running all the time and the other two sharing the remaining core 50/50.

Setting your resources at 50/25/25 as MarkJ said wont be as clear cut as you probably would like. From time to time you may see the same project running on both cores and it wont necessarily be your favorite project. But, in the long run, the CPU time allocated to the projects will reflect the ratio you choose.

Edit:
Also, the credits you receive will not exactly reflect the ratio since the credit/time isn't exactly the same across all project, with some giving out more and other less than the average depending on the project.

Hi,

I too have been wondering if it was possible to dedicate one processor entirely to one single project, and leaving the other one shift between the other projects I am interested in.

It turns out that it is not as easy as one would think, mainly for two reasons.

1) Tasks that would run on high priority, be it needed or not. (Spinhenge and Magnetism@home just to mention a couple)
Boinc seems to prioritize these projects especially if the client has another long task (i.e. any climateprediction) in his queue.

2) High number of projects partaken in: even if you set resources on a 50/25/25 type scheme, there will be some project taking over the one you have set for maximum resource share.

Dedicating processor time on the proportion of the resources is probably a long term kind of thing.
Maybe many users, like myself and Bur would agree to give other projects a hand on the condition that this does not affect their favorite project.
I feel this is not achieved with the current solution.

Dedicating a core to one project exclusively would allow the other to crunch for all the other projects, while boinc benchmarking would allow for download of tasks that can be finished by that single processor and not interfering with the first one for finishing high priority tasks.

Does this make any sense? Is it too hard to implement in Boinc Manager?

Thanks

I have always hated this about BOINC. Why can't someone write a better algorithm for prioritizing projects based on availability of WUs? For example:

1. Run FaveProject@Home at all times unless no WUs available.
2. Run 2ndFaveProject@Home until FaveProject@Home has more WUs.
3. Run 3rdFaveProject@Home when 1 & 2 both have no WUs.
etc.

Currently the best workaround is to set your favorite project's priority to 1000 and everything else to 1; and to babysit BOINC all the time, suspending other projects when your favorite one releases a batch of WUs (SIMAP users know what I'm talking about). Alternatively, you could have your computer connected only to one project, but then it would sit idle when that project is out of work.

It's as if the resource manager was written collectively by the owners of the least popular projects in order to make sure that people would throw a few FLOPs their way from time to time. Nietzsche would not be pleased with this system.

Will anyone with programming skills make a better account manager? Please!!!

---

The problem could be resolved within BOINC Manager by switching apps not based on due dates, but by the user's assigned priority. For example, it could still pull whatever WUs the current method pulls, but as long as I have FaveProject WUs on my computer, it will crunch them, regardless of their due dates, until they are all gone. Other WUs that expire sooner would just be ignored and automatically aborted locally at the time of their expiration (else the system might crunch expired WUs). This would lead to a lot of reissuing of WUs by the projects, but it would effectively penalize projects for setting ridiculously short expiration times. Currently those projects "steal" from my favorites by having a shorter expiration time and getting bumped up in the queue.

---

This would lead to a lot of reissuing of WUs by the projects, but it would effectively penalize projects for setting ridiculously short expiration times. Currently those projects "steal" from my favorites by having a shorter expiration time and getting bumped up in the queue.

Your resource shares are followed in the long term. A task with a short expiration time is processed immediately, but then no work is fetched from that project until you have crunched enough for the other projects to make the amount processed match your resource shares again.

---

Your resource shares are followed in the long term. A task with a short expiration time is processed immediately, but then no work is fetched from that project until you have crunched enough for the other projects to make the amount processed match your resource shares again.

I understand the concept, but it fails to account for the fact that at any given instant, other projects might not have any WUs available. Those projects with scarce WUs may release a few here and there, but if your machine is crunching for another project at the time, you won't get as many of those rare WUs as you may want before other users snatch them all up.

To offer an analogy, in the long term I could expect to win 49% of my hands in blackjack, assuming a random distribution of the cards. But I can increase that figure by making sure I don't play when the deck is low on tens and aces, and maximize my playing opportunity when the deck is rich-- which is done in the short term, by instantaneously reevaluating the deck as each hand is dealt.

---

I understand the concept, but it fails to account for the fact that at any given instant, other projects might not have any WUs available. Those projects with scarce WUs may release a few here and there, but if your machine is crunching for another project at the time, you won't get as many of those rare WUs as you may want before other users snatch them all up.

Give a suggestion on how it should work to account for that fact. (without breaking other common use-cases).

---

Give a suggestion on how it should work to account for that fact. (without breaking other common use-cases).

I don't know what "common-use cases" are, but my suggestion would be something like this (I have no programming skills, so bear with me):

Definition:
ProjectN (N=1,2,3...): Project name by order of personal preference. Projects of higher preference will run at all times over projects of lower preference. Multiple projects could conceivably have the same priority (e.g., Project2A & Project 2B) in which case the manager would simply divide computation time by the number of projects within that priority level. N would be assigned to each project by the user.

Algorithm:

1 Let N=0

2 N=N+1

3 Check ProjectN for WUs.

4 IF ProjectN has no WUs available, THEN goto 2, ELSE goto 5

5 Download maximum number of WUs allowed under the following restrictions:
a. Project-specified quotas
b. Host's ability to complete the WUs before they expire [the algorithm that determines this will ignore all WUs of lower N, since they will likely be aborted.]

6 Crunch WUs according to the following criteria (in decreasing order of
priority):
a. Lowest N
b. For multiple WUs of equal N, the soonest expiration time.

The host will NOT switch to a new WU until the current one is
complete.
This routine will "pause" here. Upon completion of a WU, it
will continue to line 7.

7 Evaluate remaining WUs for expiration times, and abort those without enough
time remaining, beginning with those that have zero progress and lowest N.

8 Goto 1

Unless I overlooked something, this should guarantee that the host will be dedicated at all times possible to the crunching of one's favorite project's WUs, AND that the maximum possible WUs are captured while they are available.

Yes, this will involve the abortion of "less desirable" WUs, but this would be done at the earliest possible opportunity, allowing the WUs to be redistributed to others. This could represent an increased use of bandwidth, but since WUs tend to be small, I don't see this as a big deal.

---

WUs don't "tend to be small". They may be in the projects you contribute to, but not in all. See CPDN and its hundred-megabyte WUs (which may take 4 months to process).

Your suggestion breaks the most common case: attaching to, say, three projects that 99% of the time have work available, and contributing equal amounts of CPU time to all three. Or 50% to one project and 25% to the other two.

---

Your suggestion breaks the most common case: attaching to, say, three projects that 99% of the time have work available, and contributing equal amounts of CPU time to all three. Or 50% to one project and 25% to the other two.

However, it shows what the best scheduler would be: a user-modifiable one. Users who have special requirements(*) would be able to write a scheduler script to do exactly what they want, or ask someone with programming skills to do it for them. The rest of the users could keep the default one.

(*) You're not the only one; I'm sure other people may want exactly the same behavior as you described. But I consider your requirements "special", because I think it's still a minority of users who need the scheduler that way.

---