Please report problems with this version. Thanks!

---

The home page news said: "Rosetta@home has been updated to version 5.81. This version contains small, but essential changes to the scientific protocols. For details, see this thread."

I don't see any details...

Thanks Trey. The thread link now points to the correct location.

---

Didn't you mean 5.82!, thats what i've got. ;)

Pete.

---

5.69 is 5.82 now? and 5.81 is the "new" version?

---

I'm not sure I understand the point of this thread here. I understand why it exists on RALPH, of course. But with sufficient testing on RALPH, why is this thread needed here?

---

Reno, NV
Team: SETI.USA

Thanks Trey. The thread link now points to the correct location.

Hint: youd better insert this as adress in your link ( https://boinc.bakerlab.org/rosetta/forum_thread.php?id=1449&nowrap=true#48406 ) this links directly to the post about 9.81

5.69 is 5.82 now? and 5.81 is the "new" version?

yes 5.69 is renamed to 5.82 see the homepage ;)

I'm not sure I understand the point of this thread here. I understand why it exists on RALPH, of course. But with sufficient testing on RALPH, why is this thread needed here?

Because they don't do "sufficient" testing on Ralph.....!

even if they did "sufficient" testing on Ralph, would it be perfect enough for each and every work unit generated on Rosie? the percentage of errors vs the percentage of successes is quite low but gains alot of visibility when a error does show up.

I'm not sure I understand the point of this thread here. I understand why it exists on RALPH, of course. But with sufficient testing on RALPH, why is this thread needed here?

Because they don't do "sufficient" testing on Ralph.....!

---

even if they did "sufficient" testing on Ralph, would it be perfect enough for each and every work unit generated on Rosie? the percentage of errors vs the percentage of successes is quite low but gains alot of visibility when a error does show up.

I'm not sure I understand the point of this thread here. I understand why it exists on RALPH, of course. But with sufficient testing on RALPH, why is this thread needed here?

Because they don't do "sufficient" testing on Ralph.....!

What is the percentage of errors to successes?

That would be a good thing to see for status.......less complaints if the error rate is really low.

even if they did "sufficient" testing on Ralph, would it be perfect enough for each and every work unit generated on Rosie? the percentage of errors vs the percentage of successes is quite low but gains alot of visibility when a error does show up.

I'm not sure I understand the point of this thread here. I understand why it exists on RALPH, of course. But with sufficient testing on RALPH, why is this thread needed here?

Because they don't do "sufficient" testing on Ralph.....!

What is the percentage of errors to successes?

That would be a good thing to see for status.......less complaints if the error rate is really low.

i thought for a batch of WU's the error rate is aroud 1% to 3%

At the risk of continuing to clutter this thread with non-problems... To give you a feel for number of successful results... Have a look at the reports collected by dcdc. If the result name ends in _0 then it was the first to be sent out. You will see batches all with sequential names followed by batches of a mixture of names. These mixtures of names are the result IDs created in between the project creating new work. They are generated automatically when a result misses it's deadline, or completes with an error. So you can see the number of WU names ending in _1 or _2 is very small. And many of those are probably due to missed deadlines, not failures.

Perhaps dcdc could run some more numbers and provide a more specific answer to the question.

---

Add this signature to your EMail:
Running Microsoft's "System Idle Process" will never help cure cancer, AIDS nor Alzheimer's. But running Rosetta@home just might!
https://boinc.bakerlab.org/rosetta/

At the risk of continuing to clutter this thread with non-problems... To give you a feel for number of successful results... Have a look at the reports collected by dcdc. If the result name ends in _0 then it was the first to be sent out. You will see batches all with sequential names followed by batches of a mixture of names. These mixtures of names are the result IDs created in between the project creating new work. They are generated automatically when a result misses it's deadline, or completes with an error. So you can see the number of WU names ending in _1 or _2 is very small. And many of those are probably due to missed deadlines, not failures.

Perhaps dcdc could run some more numbers and provide a more specific answer to the question.

i have a unstarted WU in my batch that ends with _1 the rest ends with _o, so that 1 is doomed to fail?

but we shouldn't be discussing this kind of things here. (a)

Way off topic.
Luuklag - Thinks you have the wrong end of the stick!
Would hate to think you were aborted WUs unnecessarily.
the ...0 or ...1 at the end of each WU means that it has been sent out previously ...0 times or ...1 times.
The WU to which I referred was one that had been sent and returned to another PC, but returned after the deadline for that WU {Duplicated WU thread} - credits had been applied to the original cruncher so there would have been no point in my crunching that WU again as it had been happpily accepted by Rosie and if I had crunched it there would have been NO credits for me.
You can always check the reason for any...1 WUs that you have in your results {awaiting processing} and see why it was sent out again. There was a time a few months ago that some WUs were sent out that had been crunched but returned after the deadline so the second cruncher would get no credits and that WU had been accepted by Rosie.

---

And now about reporting problems with Beta 5.81 : 8 out of 9 WU's I had ended in "compute error" al results start with "maximum disk usage exceeded" and then get an "unhandled exception detected".
The first msg does not compute for me because my disk is nowhere near full, neither is Boinc near it's limit on disk usage.
The second msg is one for the specialists, my computer is not hidden so take a look and see what you can find.
I hope the problem is solved quickly, I'm wasting good CPU time here.
Will keep crunching for now.

Rob.

---

Hi Rob,

The latest WU I crunched so far was the: 1fe6__BOINC_SYMM_FOLD_AND_DOCK_RELAX-1fe6_-crystal_foldanddock__2257_31479_0
As all your Maximum disk usage exceeded Wu's: __2257_.
The 1fe6__etc. had a odd behavior: The RMSD was very high, it was not visible in its graphic. The memory usage was high: 411060 kB Ram, & 606092 kB of swap page max. (according to Process Explorer).

I wonder if a low swap page might give you a Maximum disk usage exceeded error.

Keep on crunching,
Path7.

At the risk of continuing to clutter this thread with non-problems... To give you a feel for number of successful results... Have a look at the reports collected by dcdc. If the result name ends in _0 then it was the first to be sent out. You will see batches all with sequential names followed by batches of a mixture of names. These mixtures of names are the result IDs created in between the project creating new work. They are generated automatically when a result misses it's deadline, or completes with an error. So you can see the number of WU names ending in _1 or _2 is very small. And many of those are probably due to missed deadlines, not failures.

Perhaps dcdc could run some more numbers and provide a more specific answer to the question.

i have a unstarted WU in my batch that ends with _1 the rest ends with _o, so that 1 is doomed to fail?

guess what it failed...
but we shouldn't be discussing this kind of things here. (a)

Hi Rob,

The latest WU I crunched so far was the: 1fe6__BOINC_SYMM_FOLD_AND_DOCK_RELAX-1fe6_-crystal_foldanddock__2257_31479_0
As all your Maximum disk usage exceeded Wu's: __2257_.
The 1fe6__etc. had a odd behavior: The RMSD was very high, it was not visible in its graphic. The memory usage was high: 411060 kB Ram, & 606092 kB of swap page max. (according to Process Explorer).

I wonder if a low swap page might give you a Maximum disk usage exceeded error.

Keep on crunching,
Path7.

Thanks for the insight, but the available swap space is 4.4 GB so that shouldn't be a problem.
To be sure I changed the 'use at most .... disk space' setting from 1 to 2 GB.
We'll see if that helps.

Rob.

There is a maximum to the size that the output file for a WU is allowed to reach. That must be the limit that you hit.

Batch 2257, sometimes with less then 1000 seconds of processing completed.

---

Rosetta Moderator: Mod.Sense