I tried it without WCG. Only rosetta and gpugrid together, but no luck.

GPUgrid, that's running on GPU, isn't it? Try without that. Some of your machines are completing Rosetta tasks successfully, are that those without GPU crunching?

do the errors occur only or mostly on machines also running GPU tasks? Or also on machines without GPUs used for crunching? Some people reported that in the other thread. BTW, minirosetta 3.41 is out, you could try that.

You have two problems...1st is you are using an unapproved version of Boinc here at Rosetta, they have NOT approved the version 7.X.X series yet and you are using version 7.0.31. 2nd you are also gpu crunching with your pc, that is another deal breaker for the Rosetta workunits, they do not share well with others! Rosetta has consistently said they are happy with the settings they have and are not going to be changing them.

Since your computers are hidden I can only guess, but probably you are throwing out only errors (on a 8 core machine). Unhide your computers, than we can eventually see the reason.

greb_be and all,

When there is a new version of minirosetta update, we usually put a windows debug symbol image in a downloadable location. So when a WU crashes out, it should provide a backtrace of how an error is caused (this does not work every time and that makes our debugging very hard). If it is an error from Minirosetta program or bad command line/input file setup, the stdout or stderr usually will print out a message as hints, for example, the hbond NAN problem in the previous versions. Also, we should see a significantly higher error rate among either all or certain batches of WUs running. If it is caused by interfacing with the host's hardware or software, we will usually see that certain client hosts kept encountering errors or failure. We wish we could tell what have been wrong in every scenario when an error occurs, however, most of us Rosetta developer are far from being an expert on computer software/hardware and we can only hope to trap errors locally on our testing machines to continue with debugging.

Thank you all for voluntarily helping us on doing this project and sorry about any inconvenience/trouble caused on your computer. Please continue to report problems and/or possible fixes you have found as every bit of such information will certainly help us to improve R@H stability and resolve hidden bugs/problems sooner or later. Happy holidays to every one and happy crunching!

Chu,

Thanks for replying. I suspect its my over clock speed. If you have that many clients returning good tasks and I see the last one I posted went through to another client ok, I have to assume my speed is to high for these tasks on RAH.
I dropped the speed by 10 mhz to see if that corrects the problem, if it continues then I will drop it some more until things become steady. as of a week ago I could run at the faster speed with no problems. But this week the majority die.

Normally when my speed is to high, the tasks fail immediately. So I don't understand how a task can run eight thousand seconds and then crash. I had another one that ran up to 10 mins of completion and died.

Can you tell me how to see the difference between a error due to windows or OC speed vs a program error that triggers a windows dump with '-1073741819 (0xc0000005)'?

Thanks again for the reply.