Mine all run 8 hours.

I grabbed the results from 6, first 6 I found and they weren't by beta/whatever, they averaged 3h 33m. I do have some older slower computers that weren't included.

Perhaps one of the wizards around here can explain to me what the Project Resource share is, they're all set to 100, and how to set it for each project (without going in and manually editing the xml files). From my experience WCG will overrun boinc if given the opportunity.

---

Second biggest issue seems to be the incorrect setting of default runtimes to 4hrs on tasks running through Rosetta Beta 6.06 - instead of 8hrs

Strange: Mine all run 8 hours. I have seven of those running right now on Linux.

The new RosettaVS tasks have been running for 8 hours, the others are still running for 4 hours.

The important part is the scientific results

Doubly agree!

---

Second biggest issue seems to be the incorrect setting of default runtimes to 4hrs on tasks running through Rosetta Beta 6.06 - instead of 8hrs

Strange: Mine all run 8 hours. I have seven of those running right now on Linux.

If you set a Target CPU Time then they will run for that length of time.
If you leave it blank- ie the Default Target CPU time then they will run for as long as the project determines they need to run.
For Rosetta 4.20 Tasks the default is 8 hours. For the Beta Tasks the default is usually 3 hours, sometimes it can be 8 hours.

---

Grant
Darwin NT

Mine all run 8 hours.

I grabbed the results from 6, first 6 I found and they weren't by beta/whatever, they averaged 3h 33m. I do have some older slower computers that weren't included.

You have set your Target CPU run time to 4 hours, so that is how long they will run for- unless they will run longer than that time in order complete in which case they will end before the 4 hours.

Perhaps one of the wizards around here can explain to me what the Project Resource share is, they're all set to 100, and how to set it for each project (without going in and manually editing the xml files). From my experience WCG will overrun boinc if given the opportunity.

The Resource share setting is a ratio, not a percentage (the BOINC manager shows in brackets what it is as a percentage next to the resource share value).
You set the percentage in the Computing preferences for the particular project you wish to increase or decrease the allocation of computing resources.

What is being shared is not computing time. eg- 2 projects, one with an extremely efficient application, the other with an extremely inefficient application. Equal Resource share values.
The efficient application project may only run a Task every few days, the other may run dozens of Tasks every single day. The amount of time is obviously very different, however the amount of computing actually done is the same (as per Resource share settings). It is not based on the Credit (RAC) awarded by the projects.

If a project is down for a while, then all the other projects will get that computing resource (time). When the down project comes back up, it will get the lion's share of computing resources (time) until your Resource share settings are being met in which case it will reduce the work on that project & increase the work for the other projects again to maintain that.



The larger your cache, the more projects you run, the less time BOINC has to process work (ie system on for limited hours, BOINC limited in when it can do work during those hours, limit on the number of cores/threads it can use, limit on Use at most % of CPU time, Suspend when non-BOINC CPU usage is above is less than 100%), the more you micro manage BOINC then the longer it will take for your Resource share settings to be honoured- we are talking months here.
More than one project, then no cache is best (0.1 days and 0.01 additional days), and your Resource share settings should be honoured within a few days to a week (of course if a project/ more than one project are having issues with sending or receiving work, then that will cause things to fluctuate).

---

Grant
Darwin NT

Second biggest issue seems to be the incorrect setting of default runtimes to 4hrs on tasks running through Rosetta Beta 6.06 - instead of 8hrs

Strange: Mine all run 8 hours. I have seven of those running right now on Linux.

Admittedly this issue is one I report second-hand - it doesn't happen to me as I personally force 12hr runtimes.
As you can see from the comments of others there are "issues" with runtimes internal to some tasks, even though the default in Boinc begins at 8hrs for all tasks, so it messes up BOINC's scheduling as well.
Good to read that the new RosettaVS tasks run correctly to 8hrs, but it should be the default for all tasks.

---

Third biggest issue is the daily cleanup job that awards credit to tasks with Validation failures (without Compute errors). This job hasn't run for a year or more

In case anyone hasn't noticed this particular issue, I had it happen to me just today
See here
Ran perfectly, completed successfully, validation fails for no known reason - no credit.
The daily cleanup job looked for these instances and awarded due credit. Doesn't run any more
Very annoying

It also just happened to one task on my other home PC.
I was under the impression it was very rare, so only a small issue, but now I check, it happens more often than I thought.
Also, the latest batch of work seems to be reporting a disappointingly high rate of errors again.

---

Perhaps one of the wizards around here can explain to me what the Project Resource share is, they're all set to 100, and how to set it for each project (without going in and manually editing the xml files). From my experience WCG will overrun boinc if given the opportunity.

It allows you to set a weighting for each project.
For Rosetta, click Your Account in Boinc manager, then chose Rosetta@homepreferences and edit it as desired.
Fwiw I weight Rosetta 2900, WCG 100, SiDock 100 to get a majority Rosetta processed while there's work.
(Note: the figure chosen isn't a %age)

---

Ahhh...thanks, and you too Grant.

I now have it set as DENIS@home 200 (no work there anyhow), Rosetta@home 500, WCG 100, and Einstein@Home 100.
But I limit Einstein to 1 thread via it's app_config.xml file (on a couple of machines, the rest have stopped downloads completely). I'll watch things for a week or so.

---