If I set resource share to 10, I still pull down about 5x the work of any of the other projects I crunch on.

It takes a while for the work units to adjust to a new resource share setting (often several weeks).

In order to speed up this process, you can use a cc_config.xml file (placed in the BOINC Program Data folder) with the following,
which will speed up the convergence to a day or two:

<cc_config>
  <options>	
  	<rec_half_life_days>1.000000</rec_half_life_days>
  </options>
</cc_config>

Or you can chose any other value. I routinely use it when setting up a new machine.

---

If I set resource share to 10, I still pull down about 5x the work of any of the other projects I crunch on.

It takes a while for the work units to adjust to a new resource share setting (often several weeks).
...

<rec_half_life_days>1.000000</rec_half_life_days>

...
Or you can chose any other value. I routinely use it when setting up a new machine.

That's awesome. I completely missed that, and it looks like exactly what I needed. A++ Kudos, and thank you very much.

-JD

You are welcome. It is from Richard Haselgrove, the great BOINC guru.

---

Yesterday evening in europe took place a little upgrade of rosetta server because he was one hour along down.

---

Guy PFLIEGER MASEVAUX ALSACE France
phone: 0033973514697

I have in my preferences CPU time of 1 hour. Seems to ignore it and I have just wasted over 18,000 seconds on a job that got a validate error.

Just finishing the rest then I am not processing any more tasks.

It seems with the calculation of the amount of workunits is someting really wrong.
My default runtime is set to 24 hours. So, Rosetta runs each WU for 24 hours. That works very well. But: Boinc is still to dumb to realize that.
The calculated runtime for new WU's is always around 4 hours. So, i receive tooo much WU's which i have to cancel all the time. Otherwise crunch i only WU's which are ready after deadline ends.
I have no other project running.
Interesting is, i crunch 6 WU's at the same time (6 of 8 CPU cores), 4 hours sets Boinc as runtime for new WU's -> 6*4 = 24
On my other PC is it 4 WU's at the same time and Boinc sets 6 hours for new WU's.
Both Windows, differend Boinc versions. Android is still woking fine.

---

Hi,

is there any chance for adding support for ARM platforms + Linux to rosetta project? Would like to run it on my Raspberry pi 3, or other ARMs.

This is the error log from the Raspberry running the Ubuntu Linux:

13-Feb-2018 20:42:58 [https://boinc.bakerlab.org/rosetta/] Requesting new tasks for CPU
13-Feb-2018 20:43:01 [Rosetta@home] Scheduler request completed: got 0 new tasks
13-Feb-2018 20:43:01 [Rosetta@home] This project is using an old URL.  When convenient, remove the project, then add https://boinc.bakerlab.org/rosetta/
13-Feb-2018 20:43:01 [Rosetta@home] This project doesn't support computers of type arm-unknown-linux-gnueabihf

Note that this works e.g. for Einstein@Home.

Is there a known communication issue with 7.8.6 for Mac? I've got 7.8.4 and 7.83 clients that have contacted the project as recently as 2 hours ago and my two 7.8.6 clients on Mac keep deferring communication.

Is there a known communication issue with 7.8.6 for Mac?

There is a new 7.9.1 experimental version out for Mac, but I don't know what it fixes.
http://boinc.berkeley.edu/dl/?C=M;O=D

---

Are you sure that 1 hour is even an allowed value for CPU time? I haven't checked lately, bu 3 hours used to be the lowest allowed value.

Re re: Is there a known communication issue with 7.8.6 for Mac?

Re: There is a new 7.9.1 experimental version out for Mac, but I don't know what it fixes.
http://boinc.berkeley.edu/dl/?C=M;O=D

Have the same problem. 7.9.1 does not fix it.

Re re: Is there a known communication issue with 7.8.6 for Mac?

Re: There is a new 7.9.1 experimental version out for Mac, but I don't know what it fixes.
http://boinc.berkeley.edu/dl/?C=M;O=D

Have the same problem. 7.9.1 does not fix it.

Downgrading to 7.8.4 or to 7.6.22 also does not solve it.
I only run Rosetta, it would be nice if someone could comment about whether other projects are also affected or not.
I suspect it might be a Rosetta server problem, not a Boinc problem.

Whatever the problem was, it seems to have been corrected / disappeared.

Re re: Is there a known communication issue with 7.8.6 for Mac?

Re: There is a new 7.9.1 experimental version out for Mac, but I don't know what it fixes.
http://boinc.berkeley.edu/dl/?C=M;O=D

Have the same problem. 7.9.1 does not fix it.

Downgrading to 7.8.4 or to 7.6.22 also does not solve it.
I only run Rosetta, it would be nice if someone could comment about whether other projects are also affected or not.
I suspect it might be a Rosetta server problem, not a Boinc problem.

Have been mining for over a week but computer # not syncing with profile. My profile show no computers attached, but grcpool is linking to a valid computer...https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=3351394

please assist in syncing processing computer with rosetta account, so I can get credit for processing.

It seems when BOINC requests work, Rosetta sends more than requested.
I do not have this problem with any other project.
This is worse as of the last week or so, but it does not always happen this way.

The main system I notice this on is here:
https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=3290081

My runtimes closely match what I've selected in project properties, so it's not that.

If I set resource share to 10, I still pull down about 5x the work of any of the other projects I crunch on.

Deadline is around a week out, so this forces other projects to not run, in favor of Rosetta, because eventually it wants to make sure the jobs are not at risk.

When it uploads the work, it grabs new replacement work, and still favors Rosetta.

I've opened a similar thread in the BOINC forums, since I think they should force the scheduler to comply with user wishes, not with what the project sends.

But I see it as a problem with both sides.

I'm hoping to get a workaround, or some sort of dev committment to help improve this situation.

I've just responded to another user who's having problems who has a 1hr runtime set. I have no idea why this is happening, but the default runtime should be 8hrs and Boinc should only be sending one-eighth of the tasks than the 277 that you're showing.

Is this a consequence of some auto setup coming from mining sites or something? Because it's massively wrong and could lead to problems with the website as well as individual users with bad settings.

See my reply here:

---

Are you sure that 1 hour is even an allowed value for CPU time? I haven't checked lately, but 3 hours used to be the lowest allowed value.

3hrs used to be the default, but 1hr was (and still is) the minimum allowed.

I agree the 1hr option should be removed. And with so many multi-core processors out there, the minimum should probably be 3hrs. 2hrs is also a current option.

---

Have been mining for over a week but computer # not syncing with profile. My profile show no computers attached, but grcpool is linking to a valid computer... https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=3351394

please assist in syncing processing computer with rosetta account, so I can get credit for processing.

The link to the PC you provided is showing credits, but that's not the account you're posting to here which, as you say, shows no credit or attached PC.

I'm probably very naïve or stupid, but I don't understand what you're asking.

You mention "mining" and my eyes roll over, mainly because I don't understand a thing about it. But it seems to me you should be asking whoever you're mining for, because they're getting all the credits right now istm. Is there some other website somewhere which subsequently grants you some share (they claim to be) attributable to you? Ask there. No-one here will ever know a thing about it afaik.

Maybe someone can PM me to tell me what all this mining stuff is all about - before I embarrass myself and others by saying something I may regret #CanYouSayRipOff

---

Are you sure that 1 hour is even an allowed value for CPU time? I haven't checked lately, but 3 hours used to be the lowest allowed value.

3hrs used to be the default, but 1hr was (and still is) the minimum allowed.

I agree the 1hr option should be removed. And with so many multi-core processors out there, the minimum should probably be 3hrs. 2hrs is also a current option.

Due to the tasks running for 6 hours then having computation errors its better to have the 1 hour task. Then once it reaches 2-3 hours its know to be bad and can be manually aborted instead of wasting a full 6 hours.

Are you sure that 1 hour is even an allowed value for CPU time? I haven't checked lately, but 3 hours used to be the lowest allowed value.

3hrs used to be the default, but 1hr was (and still is) the minimum allowed.

I agree the 1hr option should be removed. And with so many multi-core processors out there, the minimum should probably be 3hrs. 2hrs is also a current option.

Due to the tasks running for 6 hours then having computation errors its better to have the 1 hour task. Then once it reaches 2-3 hours its know to be bad and can be manually aborted instead of wasting a full 6 hours.

Depends on what caused the computation error.

Each Rosetta@Home task is composed of, usually, 100 subtasks. The first of these only check that the computer is handling such tasks properly; if it is the only one completed, the results of the task are useless.

The other 99 are either from 99 different starting points, or 99 iterations from one starting point. Only as many are actually done as will fit into the time allowed.

If the cause of the computation error is in only one starting point, it's probably best to run as many subtasks as will complete before reaching this starting point, since that many subtasks are not leading to a computation error. I don't think the project has mentioned whether they can recover output from all the properly completed subtasks if a later subtask gives a computation error.

On the other hand, if the cause of the computation error is in an input file shared by all 99 of these subtasks, it is best for the first one to detect the error and stop the whole task.

Note that allowing longer runs reduces the amount of communications time required to get input files from the server to your computer and get the output files back.

Are you sure that 1 hour is even an allowed value for CPU time? I haven't checked lately, but 3 hours used to be the lowest allowed value.

3hrs used to be the default, but 1hr was (and still is) the minimum allowed.

I agree the 1hr option should be removed. And with so many multi-core processors out there, the minimum should probably be 3hrs. 2hrs is also a current option.

Due to the tasks running for 6 hours then having computation errors its better to have the 1 hour task. Then once it reaches 2-3 hours its know to be bad and can be manually aborted instead of wasting a full 6 hours.

Depends on what caused the computation error.

Quite.

Everyone seems to have gone away. Probably just as well.
No-one mailed me about mining. Probably just as well too.

I think the minimum task runtime should be changed up anyway, before anyone comes back.

I've replaced an old machine with a new one over the last month and been overclocking it gradually, ending up with loads of aborted tasks after I went a bit too far (corrected now). I wouldn't mind betting these other guys have been overclocking too and Rosetta has found their machines' weak spots. Just guessing though.

---