Newly-downloaded workunits have a deadline of 10 to 14 days whereas seti@home, e.g., workunits vary from 20 to 40 days. Boinc then runs all cpu's on running, high priority for the rosetta task. Rosetta has to be suspended as a project for a while to achieve fairness across projects. Has anyone else noticed how Rosetta doesn't "work and play well with others"?
Yes, I can manually override, but it's cool at the rare times when one cpu runs Rosetta and another runs seti (or orbit@home if they ever get funding).
Observations?

Newly-downloaded workunits have a deadline of 10 to 14 days whereas seti@home, e.g., workunits vary from 20 to 40 days. Boinc then runs all cpu's on running, high priority for the rosetta task. Rosetta has to be suspended as a project for a while to achieve fairness across projects. Has anyone else noticed how Rosetta doesn't "work and play well with others"?
Yes, I can manually override, but it's cool at the rare times when one cpu runs Rosetta and another runs seti (or orbit@home if they ever get funding).
Observations?

This is really a question for the Number crunching section but your problem is not going to be solved anytime soon. It has been going ever since Boinc started in 1999 and more than one project, there are now dozens of active Boinc projects, and each one gets to set its own deadlines as it sees fit. Malaria chooses short ones as they actively use the research, or did, in physically changing the on the ground field trials based on our crunching results! Some projects want to remain fairly small and keep the costs down so the storage requirements are kept small by storing fewer workunits overall. Everytime they have a deadline some people will miss it, that means those units must be tracked to know thry originally went to pc A and now cannot go back to that pc but instead must go to some other pc. MOST projects have a default of 2 of the exact same workunits sent 2 different pc's so they can hopefully each return a numerically significant answer. Again if that doesn't happen the units keeps getting sent out to another pc until 2 do match up. then alot of people never return units early, they are almost always near the end of the deadline, that again is alot of storage space for each project to maintain, and us users to scream and complain about when it goes down.

The easy answer is for you to reduce your cache size to the lowest deadline of the projects you crunch for, that will make your pc contact each project more often but also keep Boinc happy. Another way is to change the projects priority under Your Account and put Seti in you case at 50% and Rosetta at 100%, that means that 100% of the time, more or less, Rosetta will be crunched but only 50% of the time Seti will be crunched, this will reduce Seti cache size of units stored on your machine.

Each Boinc Project is individually owned, financed and supported, the basic thing they share is the Boinc Server side of the software which gives them access to you and I.

Just to clarify, the resource shares, for the example below of 50 and 100 are not percentages. Indeed the total would be 150%. They just assert relative importance. The percentage would actually be if you add the two (or more) numbers together (tallying all projects a given machine is attached to) and then dividing each project's resource share by that total.

So, for the example, SETI 50 and Rosetta 100, your total is 150. It boils down to saying you want SETI to run 33% of the time (50/150) and Rosetta to run 67% of the time (100/150). You set the resource shares any way you like to achieve the desired balance between projects. Just keep in mind it may take your machine a while to adjust to changes in this area. In general, you don't want to be making changes when you have a large cache of work already downloaded.

---

Rosetta Moderator: Mod.Sense

Just to clarify, the resource shares, for the example below of 50 and 100 are not percentages. Indeed the total would be 150%. They just assert relative importance. The percentage would actually be if you add the two (or more) numbers together (tallying all projects a given machine is attached to) and then dividing each project's resource share by that total.

So, for the example, SETI 50 and Rosetta 100, your total is 150. It boils down to saying you want SETI to run 33% of the time (50/150) and Rosetta to run 67% of the time (100/150). You set the resource shares any way you like to achieve the desired balance between projects. Just keep in mind it may take your machine a while to adjust to changes in this area. In general, you don't want to be making changes when you have a large cache of work already downloaded.

Thank you for making that MUCH clearer, and more correct, than I did!

Thank you for explaining.

Thank you for explaining.

I am glad it helped.