"Rosetta Mini for Android is not available for you type of computer"

??

Edit: SOLVED. Restart boinc client and receive new work

Re-edit: NOT Solved.
Continue to request Rosetta Mini for Android on my Windows 10 with Amd Fx

That is odd. I also updated the android application. But the boinc client should take care of the app management of different platforms etc.

---

That is odd. I also updated the android application. But the boinc client should take care of the app management of different platforms etc.

Same problem on my intel notebook....

Some errors:
3716117

Unhandled Exception Detected...

- Unhandled Exception Record -
Reason: Out Of Memory (C++ Exception) (0xe06d7363) at address 0x73162ED2

Engaging BOINC Windows Runtime Debugger...

This error is due to the large memory requirement of the test job. I resubmitted the job with a memory bound which hopefully should avoid such errors.

---

Sorry, I was too busy to reply and my system was done today...

Restarted now and checked again: no more problem!

The only difference was a reboot after a classical W7-64 KB patches applied...

When I got the error, using PE, I found one thread in ntdll.dll that call a RtlSomething function that neither return (sorry, I didn't pick the full name at that moment). It was the only thread started or remaining after a kill attempt (the main app was killed, only the graphics part stayed in memory)

So, I will continue to check regularly if that behavior happen again and report it in case...

FYI, Graphic driver: Intel HD Graphics 4600, version 10.18.14.4264

Process Explorer when working as expected:

---

Two Android phones:

Newer unit is a Motorola Droid RAZR MAXX XT912 with Android 4.1.2, host 36214
Seems to be working mostly okay with 3.71 tasks. 9 of 34 tasks report validation errors, where the task report shows a file_xfer_error, i.e., 3718881
upload failure: <file_xfer_error>
<file_name>simple_cycpep_predict_example_20280_97_1_0</file_name>
<error_code>-161</error_code>
</file_xfer_error>

Older unit is a Motorola Droid X2 with Android 2.3.5, host 36252
All tasks error out with a signal 11, i.e., 3718646

Both devices are using older BOINC version 7.0.36 from NativeBOINC

boinccmd --host ed-droidmaxx --get_host_info
timezone: -18000
domain name: droidmaxx
IP addr: 68e4:ffbe::d93d:540
#CPUS: 2
CPU vendor: ARM
CPU model: ARMv7 Processor rev 3 (v7l) @1200MHz
CPU FP OPS: 944491591.072010
CPU int OPS: 2013178288.104389
CPU mem BW: 1000000000.000000
OS name: Android
OS version: 3.0.8-gbacb1cf
mem size: 881475584.000000
cache size: -1.000000
swap size: 0.000000
disk size: 3228372992.000000
disk free: 1205657600.000000

boinccmd --host ed-droidx2 --get_host_info
timezone: -18000
domain name: ed-droidx2
IP addr: 804:0:8822:87be:400:0:4:0
#CPUS: 2
CPU vendor: ARM
CPU model: ARMv7 Processor rev 0 (v7l) @1000MHz
CPU FP OPS: 719713184.931507
CPU int OPS: 1417059093.091529
CPU mem BW: 1000000000.000000
OS name: Android
OS version: 2.6.32.9-00008-gc406305
mem size: 423706624.000000
cache size: -1.000000
swap size: 0.000000
disk size: 2113744896.000000
disk free: 1497886720.000000

The android app requires Android version 4.1+. I'm not sure what is going on with your Motorola. Seems to run ok. Are there any network issues?

---

I will remove it from the older device then (I missed the 4.1+ version requirement).

For the XT912, I also don't understand the error. I've never had any network issues (I monitor it with a remote boinc-gui, and also ping it every 5 seconds). The device also has plenty of free storage.

Ver 3.71 FAILED for both of us who ran this task:

Task ID 3722270

Name gaurav_design13_SAVE_ALL_OUT_20284_27_1

======================================================
DONE ::     2 starting structures  28399.3 cpu seconds
This process generated     56 decoys from      56 attempts
======================================================
BOINC :: WS_max 2.1257e+008

BOINC :: Watchdog shutting down...
BOINC :: BOINC support services shutting down cleanly ...
called boinc_finish

</stderr_txt>
<message>
upload failure: <file_xfer_error>
  <file_name>gaurav_design13_SAVE_ALL_OUT_20284_27_1_0</file_name>
  <error_code>-161 (not found)</error_code>
</file_xfer_error>

</message>
]]>
Validate state	Invalid
Claimed credit	93.8624553758775
Granted credit	0
application version	3.71

---

thanks, there is an error in the job submission and will get fixed. I alerted the researcher that submitted these tests about the issue and fix.

---

The graphics application was also updated to include new colors and a light source for spacefill rendering used for the new cyclic peptide modeling protocol. Spacefill rendering is only used as default for this protocol since the additional graphics load is minimal due to the small size of the proteins to be modeled.

Is this the new graph??
Screen

Is this the new graph??
Screen

And error of this wu

<message>
upload failure: <file_xfer_error>
<file_name>gaurav_rsmn_0161_65_daa2_SAVE_ALL_OUT_20295_39_1_0</file_name>
<error_code>-161 (not found)</error_code>
</file_xfer_error>

</message>

The current Ralph WUs use huge amounts of RAM, I've seen up to 4 Gb per unit, is it on purpose? any new kind of simulation?

thanks for the info

"Is this the new graph??"

Yes.

---

The current Ralph WUs use huge amounts of RAM, I've seen up to 4 Gb per unit, is it on purpose? any new kind of simulation?

thanks for the info

Yes, I'm running a test of a new type of job that runs small perturbations of the protein backbone and then does a round of design. The design protocol can use a lot of memory. I realize that this will be problematic and will see if we can distribute these jobs to high memory machines. We may just not be able to run these on R@h.

---

The current Ralph WUs use huge amounts of RAM, I've seen up to 4 Gb per unit, is it on purpose? any new kind of simulation?

thanks for the info

Yes, I'm running a test of a new type of job that runs small perturbations of the protein backbone and then does a round of design. The design protocol can use a lot of memory. I realize that this will be problematic and will see if we can distribute these jobs to high memory machines. We may just not be able to run these on R@h.

R@H means Rosseta, doesn`t it? It is good for the investigation you could look for ways of distributing these units. The only effective way I could think of is limiting the quantity of units downloaded, by the user as in CEP project in WCG or by the project. Distributing them only to hosts with lot of memory could just not be enough if the hosts have also a lot of available threads (like mine).

A good thing I'm seeing with these units is that Boinc/Ralph seems to take into account the amount of available system memory and limits the menory used, even limiting the quantity of units in execution below the quantity of available threads, and the systems does not stall and hang as used to happen in these cases. Is it correct ?

The current Ralph WUs use huge amounts of RAM, I've seen up to 4 Gb per unit, is it on purpose? any new kind of simulation?

thanks for the info

Yes, I'm running a test of a new type of job that runs small perturbations of the protein backbone and then does a round of design. The design protocol can use a lot of memory. I realize that this will be problematic and will see if we can distribute these jobs to high memory machines. We may just not be able to run these on R@h.

R@H means Rosseta, doesn`t it? It is good for the investigation you could look for ways of distributing these units. The only effective way I could think of is limiting the quantity of units downloaded, by the user as in CEP project in WCG or by the project. Distributing them only to hosts with lot of memory could just not be enough if the hosts have also a lot of available threads (like mine).

A good thing I'm seeing with these units is that Boinc/Ralph seems to take into account the amount of available system memory and limits the menory used, even limiting the quantity of units in execution below the quantity of available threads, and the systems does not stall and hang as used to happen in these cases. Is it correct ?

I'm not sure. There haven't been that many reports of stalling/hanging etc...

I think I was able to debug our scheduler so that it should not send out these high memory jobs to low memory clients. Hopefully it can now be a matter of setting the limits.

---

I'm not sure. There haven't been that many reports of stalling/hanging etc...
I think I was able to debug our scheduler so that it should not send out these high memory jobs to low memory clients. Hopefully it can now be a matter of setting the limits.

The message is clear:

05/02/2016 07:38:34 | ralph@home | Rosetta Mini needs 7629.39 MB RAM but only 2302.58 MB is available for use.

Obviously all errors:

Unhandled Exception Detected...

- Unhandled Exception Record -
Reason: Out Of Memory (C++ Exception) (0xe06d7363) at address 0x73682ED2