Please post bugs/issues with minirosetta v1.32 here.

There is a recurring problem however in connection with multi-core systems and these "high memory requirement" WUs, which would probably need some co-operation between RAH and the folks at BOINC to resolve by modifying the scheduler logic and/or introducing more WU flags regarding expectable memory use.

I'm talking about the situation where a Rosetta WU runs on one core, and another should be started on the other core, but the combined memory use hits the memory boundary set by user preferences for the project, so it's put into the "Waiting for memory" or simply the "Waiting to run" status, then the scheduler starts another Rosetta WU which happens to be also a high memory use one, it hits the memory use cap too, put into the "Waiting for memory" status, so a third needs to be started, and so on.

Right now I have 3 Rosetta WUs in memory, two using 370MB VM each and a third with 310MB, but only one is able to run because of memory preferences, the other two are just sort of deadlocking each other as they're keeping their committed VM in use without being able to actually run so that one of them could be cleared from memory once finished and then the other one get a chance to get processed too.

I wonder if there would be a way for the project or the scheduler to check the following conditions:
- Does the client asking for new work have any high-memory WUs assigned already?
- Is it a multi-CPU system with more than one CPUs enabled for BOINC?
- Would the combined memory use for "CPUs allowed to be used" x mem requirement of one WU be higher than the allowed memory use?

If they are true, then only low-memory WUs should be sent/requested/accepted as new work to that client for the project as long as it didn't return the current high-memory one to stop the scheduler from keep starting and then suspending high-memory WUs (since it has nothing else to process for this specific project), filling up available memory with "zombie" WUs that can not run because of each other.

I am quite curious as to the relative success rate of the Capri14 WUs versus WUs of all other types.

My personal experience is that a Capri14 WU is nearly doomed to failure, no matter the Rosetta version on which it is running, while nearly all other WUs will succeed...

I sincerely hope that the CPU time that (to my layman's perspective) I seem to be wasting on Capri14 is not representative of the experience of the general population of Rosetta crunchers.

Respectfully,
David Emigh

This is puzzling -- those jobs arent taking long. We'll look into it. In the meanwhile, can your or other post links to the appropriate results that were killed?

This is puzzling -- those jobs arent taking long. We'll look into it. In the meanwhile, can your or other post links to the appropriate results that were killed?

Not support.. Okey, but I not understand this messege:

<core_client_version>5.8.17</core_client_version>
<![CDATA[
<stderr_txt>
Graphics are disabled due to configuration...

I think, rosetta have graphics, but disabled it for something...

Who can answer me: When rosetta have picture in Linux?

Are you talking about a statistic that is in your host's details page? Or are you talking about the chart on this website: http://boinc.netsoft-online.com/e107_plugins/boinc/get_cpcs.php?

I'm talking about the xml element like " <credit_per_cpu_sec>0.001260</credit_per_cpu_sec>
" found in the host.gz file. Which i believe does power the web page you were refering to.

Please especially give us some feedback on the graphics -- are you able to display them properly?

Has anyone else been having problems opening the BOINC manager from the task bar? I've had this problem at random times for at least the past 4 development releases of BOINC up to the current 5.8.3. Task manager shows both Rosetta threads taking 50/50 CPU share per normal. The only way I can open BOINC manager is if I kill the process and then restart. Anyone else seeing this? Should I consider this strictly a BOINC problem not Rosetta?

Tim

Swithching task/project works fine.. Its when bonic switches back to the "unfinished" WU is where mine hangs (says its running but its not)... Not sure its a Rosetta issue more than Boinc..

Chu

Concerning the problem with Linux machines not processing after switching
tasks/projects.

I upgraded my Linspire Linux (Debian 3.0 [2.6.10]) to Freespire Linux (2.6.14)
At this point the system has completed 3 WUs without any problems.

I am also running SETI and WCG (Genome Comparsion) on that machine.

So it appears at this point (to me) that if a user has this problem they need to
upgrade or change to a different Linux OS.

I will post IF this problem reappears.

Jim

I moved daniels' post here, as he's got Linux problems with 5.43 as well as having seen them on 5.41.

process exited with code 131 (0x83)
process got signal 11