It seems to me that the upload problem has been solved. At least, all my stuck WU's have been uploaded now.

Yes, same here. Glad whatever the problem was has been resolved.

---

All fixed! At least all the backed up stuff is now cleared out.

Atta boy Rosetta team, we knew you could do it!

Have a great week.

Cheers!

/M

---

I keep getting the message that 'Task XX exited with zero status but no finished file. If this happens repeatedly you may need to reset the project.' I have reset the project but continue to get the error. Is this an issue on my end or the project's end? Thanks!

---

I keep getting the message that 'Task XX exited with zero status but no finished file. If this happens repeatedly you may need to reset the project.' I have reset the project but continue to get the error. Is this an issue on my end or the project's end? Thanks!

Copied and pasted from an earlier answer:

On Rosetta this is usually solved by increasing the "use at most xxx% of CPU time" setting to 100. You may then want to reduce the "on multiprocessors, use at most xxx% of the processors" to something less than currently set. Most people find this handles the temperature regulation concerns (that the cpu throttling was designed to address) perfectly.

Another possible cause are virus scanners; most folks exclude BOINC from those scans or set it to run only when BOINC isn't active.

An explanation and more possible causes can be found here: BOINC FAQ Service

Please know that this only becomes a fatal error when it occurs 100 times to a particular task; at that point BOINC assumes the task will never be able to finish and gives up on it, ending it as a client error. If you see this message only occasionally it is safe to ignore it.


Best,
Snags

Hey,

I've received some work units which couldn't be finished due to a compute error. Interestingly, the second person calculating the same WU also resulted in a compute error:
https://boinc.bakerlab.org/rosetta/workunit.php?wuid=825566938
https://boinc.bakerlab.org/rosetta/workunit.php?wuid=825557307
https://boinc.bakerlab.org/rosetta/workunit.php?wuid=825537629 (still pending)

Is this common behaviour? What has happened there?

Best regards

Moved the details from Batschlach. These are Android WUs.

---

Rosetta Moderator: Mod.Sense

Hey,

I've received some work units which couldn't be finished due to a compute error. Interestingly, the second person calculating the same WU also resulted in a compute error:
https://boinc.bakerlab.org/rosetta/workunit.php?wuid=825566938
https://boinc.bakerlab.org/rosetta/workunit.php?wuid=825557307
https://boinc.bakerlab.org/rosetta/workunit.php?wuid=825537629 (still pending)

Is this common behaviour? What has happened there?

Best regards

This was a bad batch that a researcher accidentally sent out.

This was a bad batch that a researcher accidentally sent out.

Oh, I see. Thanks for your answer. And thanks for moving my post into the right thread @Mod.Sense!

Why am I having such problems getting work units?

I have over 250 cores that can be crunching but I only have, at the time of this post, 59 slots filled. This is the only project I am running so those other cores are sitting idle.

Why am I having such problems getting work units?

I have over 250 cores that can be crunching but I only have, at the time of this post, 59 slots filled. This is the only project I am running so those other cores are sitting idle.

The Server Status page is a sea of red: clearly there are problems of some sort.

The only one that needs to be up all the time is the scheduler which I've seen up and all the ones below it have been up and down. Not everything needs to be running 100% of the time for the project to function.

Set a longer queue.

Why am I having such problems getting work units?

I have over 250 cores that can be crunching but I only have, at the time of this post, 59 slots filled. This is the only project I am running so those other cores are sitting idle.

For a dual- or quad-socket machine, a "Target CPU run time" setting below 4 hours is not sustainable, IME.

Why am I having such problems getting work units?

I have over 250 cores that can be crunching but I only have, at the time of this post, 59 slots filled. This is the only project I am running so those other cores are sitting idle.

For a dual- or quad-socket machine, a "Target CPU run time" setting below 4 hours is not sustainable, IME.

Correct. Runtime <cannot> be the minimum 1 hour - especially when you have 250 cores (which is great btw).

Default run-time is 8 hours, for which you'll do 8 times the work and receive 8 times the credit, but only use 18th of the bandwidth - better for you and the project. Also, likely to reduce the occasions you have unused cores, which answers your question.

BUT! You shouldn't change directly from 1hr to 8hrs, otherwise your tasks will miss deadlines. Change up to 2hrs first, until your buffer stockpile is reduced and starts asking for more tasks. Then 3hrs - same process. Then 4hrs etc until you get to a practical level you're happy with - ideally the default 8hrs.

---

The Server Status page is a sea of red: clearly there are problems of some sort.

Still.... :-(

---

The Server Status page is a sea of red: clearly there are problems of some sort.

Still.... :-(

Sorry for the errors in the status page. I'll take a look. Everything is running as normal so you can ignore the page for now.

2 long-running tasks with a long time since the last checkpoint:

b21_ncst_0601.282._relax_SAVE_ALL_OUT_486708_29_0
Last checkpoint: 7:51:46
CPU Time: 11:56:21

b22_1_0603.18._relax_SAVE_ALL_OUT_486983_40_1
Last checkpoint: 2:54:51
CPU Time: 8:23:20

Both have a default 8 hour runtime and I'm anticipating the watchdog being the only thing that stops them running.

I've got 2 more b21 tasks in my queue. Should I abort them? Thinking I will.

---

The 1st one has just completed and given full credit (and more) for the extra runtime. Maybe I should just let them complete after all. Let me see what the other one does.

2 long-running tasks with a long time since the last checkpoint:

b21_ncst_0601.282._relax_SAVE_ALL_OUT_486708_29_0
Last checkpoint: 7:51:46
CPU Time: 11:56:21

b22_1_0603.18._relax_SAVE_ALL_OUT_486983_40_1
Last checkpoint: 2:54:51
CPU Time: 8:23:20

Both have a default 8 hour runtime and I'm anticipating the watchdog being the only thing that stops them running.

I've got 2 more b21 tasks in my queue. Should I abort them? Thinking I will.

---

2ns one not so generous, but both acknowledged the full runtime and validated properly

The 1st one has just completed and given full credit (and more) for the extra runtime. Maybe I should just let them complete after all. Let me see what the other one does.

2 long-running tasks with a long time since the last checkpoint:

b21_ncst_0601.282._relax_SAVE_ALL_OUT_486708_29_0
Last checkpoint: 7:51:46
CPU Time: 11:56:21

b22_1_0603.18._relax_SAVE_ALL_OUT_486983_40_1
Last checkpoint: 2:54:51
CPU Time: 8:23:20

Both have a default 8 hour runtime and I'm anticipating the watchdog being the only thing that stops them running.

I've got 2 more b21 tasks in my queue. Should I abort them? Thinking I will.

---

I've got a b22 task that is wrapping up, but it is crawling to completion at 99.399% Its slowly creeping at 0.01% a minute or so, its in fast relax on model 292 step 7205.

I may just abort that task as well...

920412254

Unhandled Exception Detected...

- Unhandled Exception Record -
Reason: Access Violation (0xc0000005) at address 0x00EECEF9 read attempt to address 0x11DE2000

Engaging BOINC Windows Runtime Debugger...

---