I've had a few of these on different machines:

2/19/2006 10:16:41 PM|rosetta@home|Aborting result PRODUCTION_ABINITIO_1gvp__250_35_2: exceeded CPU time limit 50195.312500
2/19/2006 10:16:41 PM|rosetta@home|Unrecoverable error for result PRODUCTION_ABINITIO_1gvp__250_35_2 (Maximum CPU time exceeded)
2/19/2006 10:16:42 PM||request_reschedule_cpus: process exited

Is there I can do to prevent this from occuring?

---

Join the Teddies@WCG

Owlie forgot to mention that the ones above were also 4.82 with the CPU time set to 4 days......

Owlie forgot to mention that the ones above were also 4.82 with the CPU time set to 4 days......

Thanks Scribbles... I set half my machines to 2 days and left the others at 4...

I got one here, result:
http://www.boinc.bakerlab.org/rosetta/result.php?resultid=11775907
WU (4.82):
http://www.boinc.bakerlab.org/rosetta/workunit.php?wuid=6142533
client:
http://www.boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=128060
error:
<core_client_version>5.2.13</core_client_version>
<message>Maximum CPU time exceeded</message>
<stderr_txt>
# random seed: 216581
# cpu_run_time_pref: 28800
</stderr_txt>

MrS

---

Scanning for our furry friends since Jan 2002

One more time :
NO_SIM_ANNEAL_BARCODE_30_1n0u_251_13883_1
NO_SIM_ANNEAL_BARCODE_30_1dtj_251_13882_1
NO_SIM_ANNEAL_BARCODE_30_1n0u_251_13879_1
PRODUCTION_ABINITIO_2chf__250_2426_1
PRODUCTION_ABINITIO_2vik__250_1994_1
PRODUCTION_ABINITIO_2chf__250_2400_1
PRODUCTION_ABINITIO_1dhn__250_911_0


This 7 wu's with an exit code "-177"

---

Thanks much for reporting these CPU time errors. It looks like
we were able to largely solve the problem in the jobs submitted
after January. We reduced the number of structures per work unit and
extending the max CPU time; none of these later jobs appear to
have given the error.

We're now setting up jobs for the updated application. As David
will explain in a note soon, we're now tapping the BOINC resources
to unleash the powerful information available in sequence "homologues"
(sequences related to the target protein and thus expected
to have nearly the same fold). Very exciting!

These next jobs should hopefully be even less likely to
trigger the max CPU time error.
We now are allowing you to set the maximum time you want
your computer to crunch (default 8 hours) before
returning us structures, rather than asking for a specific
number of structures back. So far seems to have worked on the
test server -- please do report any further Max CPU time errors
here!

---

Whoa now, what is this???

I set my cpu time for 24 hours and I get a max cpu time exceeded after 10 hours.

Here is the WU, and here is the pertinent info:

CPU time 36185.368987

stderr out

<core_client_version>5.2.14</core_client_version>
<message>Maximum CPU time exceeded
</message>
<stderr_txt>
# random seed: 910501
# cpu_run_time_pref: 86400

</stderr_txt>

Validate state Invalid
Claimed credit 101.245443882576
Granted credit 0
application version 4.81

---

I have had two 'max cpu time exceeded' errors reported since upgrading to 4.82. It seems to have been caused by setting my 'target cpu run time' to 4hrs whilst these two WUs were already at 6+ hours of progress, or at least they both errored out shortly after I changed that value.

These are the WUs in question:

https://boinc.bakerlab.org/rosetta/result.php?resultid=11797455
https://boinc.bakerlab.org/rosetta/result.php?resultid=11796520

---

Already any progress in granting credits for MCTE WU's ??
Or did I miss it somewhere ?

---

Already any progress in granting credits for MCTE WU's ??
Or did I miss it somewhere ?

As was reported before, it will be AT LEAST mid-March before the project team can deal with the credit granting process for this class of WU failures, and maybe longer. They did say they would grant the credit in due course, but they are focused on fixing run time errors at this time. The cause of the Max time errors has been isolated and fixed so people should not see any more of them. But the credit granting process takes time.

Thanks. I'm not visiting these forums on a regularly base, so I must've missed.

---