Chilean, we are not planing to upgrade the BOINC version anytime soon but we will be upgrading the hardware in a few weeks or sooner.

Samson, it is version 3.14 due to many iterations of testing on our testing project, Ralph@home. This update includes a number of new protocols and also more methods (we call them movers) are available in our scripting protocol. We\'ll explain them in separate threads as they start getting used.

Unfortunately we omitted the graphics app for the linux platform on this update because of time constraints. It has been so long since our last graphics app update, that our build machine set up for building the graphics no longer worked with the current version of minirosetta. We\'ll try to bring it back when we have more time to look into it.

can you post the names of the workunits that are randomly hanging? the validation errors should eventually get credit.

Have to go through the logs of different machines tomorrow morning, seems to be more than one batch.
The worst is that the WU completely locks the BOINC manager out, the jobs don\'t \"release\" and switch to another project after the default of 2h as they usually do, blocking the whole system on single core CPUs when I don\'t notice it... :-(

Here\'s the worst one of today, hung at about 14%, killed it after +17h runtime, as \"normal\" jobs run 3-7h on that machine...

can you post the names of the workunits that are randomly hanging? the validation errors should eventually get credit.

Have to go through the logs of different machines tomorrow morning, seems to be more than one batch.
The worst is that the WU completely locks the BOINC manager out, the jobs don\'t \"release\" and switch to another project after the default of 2h as they usually do, blocking the whole system on single core CPUs when I don\'t notice it... :-(

Here\'s the worst one of today, hung at about 14%, killed it after +17h runtime, as \"normal\" jobs run 3-7h on that machine...

And this one I just killed this morning, stuck at 46% after 14h39m over night...
ilv_hr41_all_boinc_3h8kA_73.nonlocal.pctid_0.18.tmscore_0.49037._nonlocal_tex_IGNORE_THE_REST_27535_3084
(BOINC the only running apps for days now, on a 2GB RAM machine, no indication of RAM issues)

And this one looks hung too, 15.44% after 5h41m
casd_sr10_boinc_3e0mC_3.nonlocal.pctid_0.52.tmscore_0.68362._nonlocal_tex_IGNORE_THE_REST_27537_2047
(also XPSP3, with 3GB RAM and a couple of apps open (email, web browser) over night, as usual)

All those jobs showed a \"time to completion\" of about 3h when downloaded, which usually is within 10% high/low of the actual runtime...

And this one looks hung too, 15.44% after 5h41m
casd_sr10_boinc_3e0mC_3.nonlocal.pctid_0.52.tmscore_0.68362._nonlocal_tex_IGNORE_THE_REST_27537_2047

An hour later, the WU hasn\'t progressed 1/1000 of a %, only \"time to completion\" increased now to 14h, far away from the 3:05h runtime estimate when downloaded.
The process minirosetta_3.14_windows_intelx86.exe sits in the task manager using 295108K of RAM and 0% CPU, with +1GB of physical RAM available and a WCG WU running on the second core, with an average CPU usage about 40% while editing this on a Firefox browser tab...

I haven\'t looked through all the task that hung in the last 3 days or so, but what I referred to so far are 3 within a few hours (over night), while it used to be maybe one within a week/10 days before...

We\'ll look into this further of course. In the mean time, I\'d recommend suspending the project and aborting the work units that are stuck. Since it seems consistent on your machine, it would help us while debugging to join our Ralph@home project. We\'ll likely post an update on Ralph soon. Sorry for all the trouble.

Have you thought of creating a test application specifically to gather more information on the computer environment it is running on, then sending one such workunit to each machine known to have a problem with workunits freezing? No objection if it then goes on to attempt to run a normal workunit afterwards, possibly with more debugging output than usual enabled.

You\'d probably also want to send such workunits to a variety of other computers, to gather outputs for comparison to those from the problem computers.

For example, if it is able to capture the line from the BOINC manager log file describing the CPU capabilities, and perhaps those describing GPU capabilities, just those lines should offer a good starting point in deciding what to look for, if it happens to be something related to matching up properly to the CPU type.

We\'ll look into this further of course. In the mean time, I\'d recommend suspending the project and aborting the work units that are stuck. Since it seems consistent on your machine, it would help us while debugging to join our Ralph@home project. We\'ll likely post an update on Ralph soon. Sorry for all the trouble.

Had two more, \"freezing\" at 1.6% after 1:36h/1:40h, aborted both. Supended Rosetta@Home on this machine, then joined Ralph@Home on this machine, but got so far only

Have you thought of creating a test application specifically to gather more information on the computer environment it is running on, then sending one such workunit to each machine known to have a problem with workunits freezing? No objection if it then goes on to attempt to run a normal workunit afterwards, possibly with more debugging output than usual enabled.

You\'d probably also want to send such workunits to a variety of other computers, to gather outputs for comparison to those from the problem computers.

For example, if it is able to capture the line from the BOINC manager log file describing the CPU capabilities, and perhaps those describing GPU capabilities, just those lines should offer a good starting point in deciding what to look for, if it happens to be something related to matching up properly to the CPU type.

I don\'t see anything about the specs of the machines that would give a direct indication. It happened the most recently on 3 different ones:
- P4 2.8Mhz (single core), 2GB RAM, just sitting idle most of the time as it is my Windows 2008 test server
- Vaio notebook, also sitting idle most of the time as the build-in keyboard is reluctant to work and I need to use an external one, Pentium M760 2GHz, 2GB RAM
- my main work computer, Core 2 Duo 6300@1.866GHz, 4GB RAM (3GB avail under XPSP3)

The last one has the most \"freezes\", but always plenty of CPU and RAM to spare (average 1GB physical RAM free).