"How does it come about?" Don't know, also because the exit code 231 error only ever has been reported with HCC-GPU tasks. A previous thread discussion http://www.worldcommunitygrid.org/forums/wcg/viewthread_thread,34169 the cause is external to BOINC.

Hello Mindworks.hu,
I doubt that there is anything for you to do. The algorithm works for an adequate sample of the molecular space. The project scientists are happy. Leave these problems for them to decide whether or not to ignore.


Lawrence

Added: knred just posted about some interesting changes coming for CEP2: https://secure.worldcommunitygrid.org/forums/...ead,35152_offset,0#422494

Signal 11 is a classic on Linux, not just for CEP2, but more easily for this heavy science. BOINC needs the unimpaired connection between the process controller [boinc core client aka daemon] and the sciences at least one time per every 30 seconds. If it can't, it will often call a heartbeat condition.

I've set BOINC on Ubuntu to pause [with Leave application in memory when suspended], when non-BOINC CPU load is greater than 35%. Plus, I've added a couple of exclusive apps to the cc_config.xml such as apt-get and synaptic. When these run, BOINC is paused, no matter if run always or run based on preferences is selected. I'd rather have the crunch hold for a few minutes, than a task crash out or incur a zero status and drop back to the last checkpoint which particularly with CEP2 can mean hours of lost computing time.

If CEP2 crashes out with signal 11 and the system is idle, then review the overall system load, to include reducing to just one CEP2 at the time. There's huge amounts of IO to the storage systems which Linux is actually poor at managing... starving the client from receiving the heartbeat RPC from the science apps. When you have 4-6-8 running same time, that's on average Linux device a call for trouble. Recommended: Not run more CEP2 than 50% of all threads e.g. on a quad not more than 2 same time. Easily managed by using the 7.0.40+ client and setting <max_concurrent> in a user creatable app_config.xml file [see other threads for discussion].

Edit: P.S. The heartbeat function is a long known core client weakness. For years there's been talk to replace this system, but it depends on Berkeley. If ever replaced [so the science processes continue even if the core client is gone for a little, or quit gracefully], it will be requiring a global transition in how the apps are compiled in the wrapper [hundreds of projects around the world]. Too many different clients, old and new are around, where upgrading clients is a very major undertaking, if not impossible to reach all. The science wrapper would have to cater for legacy systems, so old and new ways are handled properly and no zombie processes are left running.