I have noticed that RALPH WUs regularly fall out of memory when the client is in paused state.

e.g. from the log file:

23/02/2006 17:17:06|ralph@home|Restarting result BARCODE_30_1cc8A_215_22_0 using rosetta_beta version 4.86
23/02/2006 17:17:06|SETI@home|Pausing result 23dc00aa.19627.28578.1009650.1.195_0 (left in memory)
23/02/2006 18:17:06|ralph@home|Pausing result BARCODE_30_1cc8A_215_22_0 (left in memory)
23/02/2006 18:17:06|SETI@home|Resuming result 23dc00aa.19627.28578.1009650.1.195_0 using setiathome version 4.11
23/02/2006 18:36:56|ralph@home|Result BARCODE_30_1cc8A_215_22_0 exited with zero status but no 'finished' file
23/02/2006 18:36:56|ralph@home|If this happens repeatedly you may need to reset the project.
23/02/2006 18:36:56||request_reschedule_cpus: process exited

As a project reset will delete all files associated with RALPH it would not make sense to do this if this failure to remain in memory is something to do with the new client under test.

Using Windows XP Pro SP2, BOINC v 4.45, Intel P4 single core no hyperthreading. Client perferences set to leave in memory. Sharing two applications RALPH@home and SETI@home.

---

I have noticed that RALPH WUs regularly fall out of memory when the client is in paused state.

e.g. from the log file:

23/02/2006 17:17:06|ralph@home|Restarting result BARCODE_30_1cc8A_215_22_0 using rosetta_beta version 4.86
23/02/2006 17:17:06|SETI@home|Pausing result 23dc00aa.19627.28578.1009650.1.195_0 (left in memory)
23/02/2006 18:17:06|ralph@home|Pausing result BARCODE_30_1cc8A_215_22_0 (left in memory)
23/02/2006 18:17:06|SETI@home|Resuming result 23dc00aa.19627.28578.1009650.1.195_0 using setiathome version 4.11
23/02/2006 18:36:56|ralph@home|Result BARCODE_30_1cc8A_215_22_0 exited with zero status but no 'finished' file
23/02/2006 18:36:56|ralph@home|If this happens repeatedly you may need to reset the project.
23/02/2006 18:36:56||request_reschedule_cpus: process exited

As a project reset will delete all files associated with RALPH it would not make sense to do this if this failure to remain in memory is something to do with the new client under test.

Using Windows XP Pro SP2, BOINC v 4.45, Intel P4 single core no hyperthreading. Client perferences set to leave in memory. Sharing two applications RALPH@home and SETI@home.

When you say "Client is in paused state", are you saying -
1) That the rosetta client application has been swapped out by BOINC to run another project application
2) You have paused the workunit from the work tab
3) you have suspended BOINC client activities from the BOINC menu
4) You have suspended the Ralph project in the projects tab in BOINC Manager.

If you are talking about 1, 3 or 3 then there is a problem, if you are talking about 4 then it might be normal

I am refering to 1 i.e. the normal swapping of applications by the BOINC core. I have noticed it happen several times. E.g. from the sample log RALPH had been paused to allow SETI to run, but in this case 19 minutes after being paused the RALPH application just dropped out of memory for no reason. It was nolonger visible in Windows Task Manager. I am using a one hour switch time.

---

To old Boinc version......

---

Teddies...

I can update BOINC Mgr and see if this helps.

---

Alas not good news.

I updated to BOINC v 5.2.13 and I am currently running Rosetta Beta 4.90. I am still getting the client dropping out of memory when it is swapped for another project and reside in memory is set on.

e.g.

28/02/2006 23:43:04|ralph@home|Result HOMSdi_homDB018_1di2__228_10_0 exited with zero status but no 'finished' file
28/02/2006 23:43:04|ralph@home|If this happens repeatedly you may need to reset the project.

When this happens you lose all credit for the work done up to this point and it restarts calculating credit when the client is becomes active again. Not an issue for RALPHA but one which would stop me running it on Rosseta live system.

The PC was only running SETI@home at the time above, no user activity, no backup, no antivirus etc was running. The PC has 1GB of RAM so there is no issue with physical memory availability.



Any ideas?

---

28/02/2006 23:43:04|ralph@home|Result HOMSdi_homDB018_1di2__228_10_0 exited with zero status but no 'finished' file
28/02/2006 23:43:04|ralph@home|If this happens repeatedly you may need to reset the project.

I had this problem frequently with rosetta@home on my WindowsXP machine. This seems to be a timing issue, when the application doesn't receive a heartbet from the Boinc CC in time and exits, because it thinks the CC has been stopped. This even happens, when the application is suspended (left in memory).
I finally discovered that a certain program doing many harddrive accesses causes this. Maybe the Windows multitasking system is not up to the job of giving those processes that need to run the cpu. The same program on a slower computer under Linux lets Boinc/rosetta work flawlessly.

The PC was only running SETI@home at the time above, no user activity, no backup, no antivirus etc was running. The PC has 1GB of RAM so there is no issue with physical memory availability.

Hmmm, perhaps Windows decided it was time to run one of those findfast-Utilities that scan your harddisks?

---

Hmmm, perhaps Windows decided it was time to run one of those findfast-Utilities that scan your harddisks?

I disabled the indexing service on my PC a long time ago as fast search is a pointless CPU wasting activity IMHO. (My Computer > Drive letter > right mouse click > properties > General tab and uncheck "Allow Indexing Service to index this disk for fast file searching". No Google or MSN desktop search either :-) The PC would only have been running SETI at the time. :-(

I have aborted the 4.90 WUs as per the news, anybody know if v 4.91 has any updates to try to address this issue? The project seems to carry on from the last checkpoint but the loss of credit would be an issue in the production environment. E.g if this were to happen one hour from the end of a 10 hour run you would only get credit for the last hour of CPU time. Looking at the result returned this WU dropped out of memory three times so this would be a common problem in production at least on my PC.

https://ralph.bakerlab.org/result.php?resultid=12783

---