Rosetta is a glutinous user of my computer's resources. It slows down my two other projects.

I didn't get any new Rosetta tasks for a while. Then it sent me more than 40 tasks, all of which had the same reporting deadline -- August 20.

There is no way my computer could complete all those tasks in the 5 days allotted for them. It takes almost 9 hours for my computer to crunch one Rosetta task. Even if I ran three Rosetta tacks at once and nothing else, that August 20 deadline could not be met. However, I think running three Rosetta tasks at once is what caused me problems in the past.

So I think it was an unreasonable expectation for Rosetta to assign 40 tasks in to be processed in five days.

Steve Gaber
Oldsmar, FL

I agree that 40 WUs in 5 days is not a realistic expectation if it takes 9 hours to complete 1 job. About the same with my systems, 8-9 hours per BOINC manager (though Minirosetta 3.78 can actually take about 12 hours "wall clock" -- or REAL time -- for me). Maybe you can adjust your BOINC Manager to lower the percentage of work doing Rosetta, or reduce the time spent on each job. Otherwise, last resort would be to guesstimate how many WUs can be done before deadline and abort the rest. On my systems if I'm running 3 or more Rosetta WUs at once my whole system gets bogged down and really slows down. I have 8G of RAM on main machine. 4G RAM on backup PC limited to 2 WUs at same time for smooth operation.

For more specific advice, I'd have to refer to you the more experienced here. Good luck.

There is no way my computer could complete all those tasks in the 5 days allotted for them. It takes almost 9 hours for my computer to crunch one Rosetta task.

What are your project preferences, particulary the "Target cpu runtime"? And the preferences in the boinc manager (store work)??

---

Boinc will adjust its work requests based on the history of a given host, but it takes some time. In your case, these jobs were in the original request and, lacking any history, it took a guess.

Now that completed jobs are being reported, it's showing a turnaround time of four days, which it should use in future calcuations. To make sure things are working as they should, look in the messages from the last time it contacted the server (or do a manual update) and it should say, "not requesting jobs, job queue full" or something to that effect. If this looks correct, I'd just let it cycle through a couple times to the next server contacts where it does request jobs to see if the number of jobs it downloads is reasonable.

Settings such as target CPU time, number of processors and stuff like that will affect Boinc's calculations, so if you want to change any of these, do that first before letting it settle out.

There are certain circumstances that require adjusting things like job queue setting but, in the majority of cases, Boinc will (eventually) do a decent job of managing the job queue.

Your own BOINC Manager requests work from project servers. The server responds to that request. This is not the server/projects fault.

An 8 hour task is the default task length unless you change it. Other apps/OS using CPU resources can push that to ~9 hours.

The initial BOINC estimates are way off, about 4 hours that I recall (I run the 24-hour work units). So until they correct themselves, I always get too many when first attaching.

To speed up the correction, you need a cc_config.xml file placed in the BOINC data folder, with this entry:

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

You then need to activate it by reading it in, or else restarting BOINC.
It should correct the time estimates in a couple of days.

---

The initial BOINC estimates are way off, about 4 hours that I recall (I run the 24-hour work units). So until they correct themselves, I always get too many when first attaching.

To speed up the correction, you need a cc_config.xml file placed in the BOINC data folder, with this entry:

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

You then need to activate it by reading it in, or else restarting BOINC.
It should correct the time estimates in a couple of days.

cc_config options require a client restart as it is only read at client startup. app_config can be read.

cc_config options require a client restart as it is only read at client startup. app_config can be read.

Thanks. I usually just reboot anyway.

---

The initial BOINC estimates are way off, about 4 hours that I recall (I run the 24-hour work units). So until they correct themselves, I always get too many when first attaching.

To speed up the correction, you need a cc_config.xml file placed in the BOINC data folder, with this entry:

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

You then need to activate it by reading it in, or else restarting BOINC.
It should correct the time estimates in a couple of days.

cc_config options require a client restart as it is only read at client startup. app_config can be read.

Not true.

Some cc_config options require a restart and some do not.
The cc_config.xml file is read at the same time as the app_config.xml files.