System Requirements : Windows XP 500MHz or higher 200MB 256MB


Thats not the problem.

quote from "additional notes" at the bottom of that page you quoted.

Additional Notes
If your computer is turned off when Rosetta@home is still running, the application will pick up where it last left off when you start it up again. You only need to connect to the internet at the beginning of a "Work" set to get input data and at the end to send back results. Some "Work" sets may not complete successfully even if your system meets the minimum requirements.

I assume (there I go assuming again) that the project is aware of the high mem useage of some "jobs". Not sure why I'm not reading anything about it, but if they need more memory to do the search they're currently doing, then so be it. I'd rather the search be more important, than someones ability to participate. I'd also hope they could cut down on that useage if they can, but if they can't???

well Takst that ask high memmory are tagged high memory and will only be send to pc's with 1024 memory, and sayd before if memory settings arent respected its a boincsoftware issue, not a rosie one. so if you pc keeps crashing check

1. dous it meet the minimum specifications for rosie
2. are memorysetting beeing violated

if both are answered with yes

then you can make a post, but dont forget to tell us: the OS your running (windows, mac, linux etc.), the boinc version, the rosie version, the wu number, the host number, if your computers are viable, helps people understand, and always quote the message log.

but before posting use your biggest friend, the "Search Forums" button, wich is found in the top left, to find if there are already threads about your error.

hope to make it this way a better forum :)

Actually Luuklag, high memory tasks go to systems with roughly 500MB of memory and higher. And I believe that is true regardless of the number of processors reported by the machine requesting the tasks. This is why some of the reported symptoms are causing people various problems.

You will see over time that the project tends to release new capabilities that consume a lot of memory, and later, as more is learned about the new capabilities, changes to use less memory are released. They are always working on reducing memory footprint. But, they are also always working on adding things that consume more memory to solve more types of proteins and to be able to apply Rosetta to problems it couldn't previously handle.

---

Rosetta Moderator: Mod.Sense

Work unit 114308970
task id 125747371
1qx8__BOINC_SYMM_FOLD_AND_DOCK_RELAX-1qx8_-crystal_foldanddock__2355_26721_0

<core_client_version>5.10.28</core_client_version>
<![CDATA[
<stderr_txt>
# cpu_run_time_pref: 14400
# random seed: 3663280
# cpu_run_time_pref: 14400
WARNING! Not sure non-ideal rotamers are compatible with symmetry yet...
WARNING! Not sure non-ideal rotamers are compatible with symmetry yet...
WARNING! Not sure non-ideal rotamers are compatible with symmetry yet...
# cpu_run_time_pref: 14400
======================================================
DONE :: 1 starting structures 8142.84 cpu seconds
This process generated 1 decoys from 1 attempts
======================================================

It died at a little over 2 hours in a 4 hour run time,but gave me credit.

---

This WU died at 16% completed. It was saying on Boinc Manager that it was running at High Priority (I don't know for how long), but in fact it was not doing anything. The CPU was running at 0% and virtual memory use was many hundreds of Megs.
Tried suspending and restarting but still no go so I aborted it. Now with a new Wu the CPU is back up to 100% usage.

---

BOINC is in control of the memory allocation, and enforcing the configured limits, not Rosetta. So for those that are seeing your configured limits exceeded, please post about it on the BOINC message boards, and at a minimum let us know your BOINC version and your platform (Linux, Mac or Windows).

With all due respect, none of the other projects I participate in have this problem. Passing the buck will not get me to reassign hosts back to this project.

Nevertheless, I am running BOINC versions 5.10.28 and 5.10.13, all on windows systems (98/2000/XP). The errors I have had occurred on both versions.

Only one of your machines meet the system requirements for Rosetta@home so if they crash don't blame the project.

From the Rosetta@home recommended system requirements page.

"If your machine does not meet the minimum system requirements, we recommend that you do not start the Rosetta@home project. If you have already started the project and decide it is too demanding on your PC, stop the BOINC client process or if you are using the BOINC Manager, "Detach" the Rosetta@home project. There may be other BOINC projects that are suitable for your machine."

Thanks, I already took care of that.

As I stated in my earlier post, a change in system requirements is something that should have been broadcast more effectively to those crunchers who have been running Rosetta@home for a long time. I accept that you want to change/update over time and that this might require new minimums for your volunteers, but Rosetta@home failed to let me in on it. I wasn't until crashes of my hosts over the last few weeks that I realized there was an issue. I don't think it should be too much to ask to be kept up-to-date on critical changes. I should have to spend time searching the forums to figure it out. It's not like you don't have my email address. A little respect, a little consideration, goes a long way. And by the way, just FYI, when I signed up, this was not a beta project.

---

I accept that you want to change/update over time and that this might require new minimums for your volunteers, but Rosetta@home failed to let me in on it. ...And by the way, just FYI, when I signed up, this was not a beta project.

As I've posted here, the minimums have not changed, so that is why no notification was made.

Rosetta@home is not a beta project. However the word "beta" appears in the application name simply because it must be kept unique in order to run two versions at the same time.

---

Rosetta Moderator: Mod.Sense

I accept that you want to change/update over time and that this might require new minimums for your volunteers, but Rosetta@home failed to let me in on it. ...And by the way, just FYI, when I signed up, this was not a beta project.

As I've posted here, the minimums have not changed, so that is why no notification was made.

Rosetta@home is not a beta project. However the word "beta" appears in the application name simply because it must be kept unique in order to run two versions at the same time.

Use another identifier other than "beta" to make that clear.

what dous it matter, a project will always be in a kind of "beta" phase since its constantly evolving, so the first release of a new algorithm or so is shure a kind of "beta" since there are more points to make it consume less memory etc, to be discovered after running for a while.

I accept that you want to change/update over time and that this might require new minimums for your volunteers, but Rosetta@home failed to let me in on it. ...And by the way, just FYI, when I signed up, this was not a beta project.

As I've posted here, the minimums have not changed, so that is why no notification was made.

Rosetta@home is not a beta project. However the word "beta" appears in the application name simply because it must be kept unique in order to run two versions at the same time.

hows does beta make it unique? there is beta 5.85 and beta 5.89 and the only thing unique about them is the .85 vs the .89 and not the 'beta' so that statement is not accurate.

i guess you could call each application version a 'beta' application because there is no final application version. by that statement we will be in beta applications forever, as it seems there could always be endlessly new 'beta' improvements.

---

This WU died at 16% completed. It was saying on Boinc Manager that it was running at High Priority (I don't know for how long), but in fact it was not doing anything. The CPU was running at 0% and virtual memory use was many hundreds of Megs.
Tried suspending and restarting but still no go so I aborted it. Now with a new Wu the CPU is back up to 100% usage.

Also had this one do the same thing. I noticed that only 3 processors were running out of 4. Boinc Manager again said that WU running in High Priority but in fact was not running at all. Could not restart WU so aborted it at 34% complete.

---

I accept that you want to change/update over time and that this might require new minimums for your volunteers, but Rosetta@home failed to let me in on it. ...And by the way, just FYI, when I signed up, this was not a beta project.

As I've posted here, the minimums have not changed, so that is why no notification was made.

Rosetta@home is not a beta project. However the word "beta" appears in the application name simply because it must be kept unique in order to run two versions at the same time.

hows does beta make it unique? there is beta 5.85 and beta 5.89 and the only thing unique about them is the .85 vs the .89 and not the 'beta' so that statement is not accurate.

i guess you could call each application version a 'beta' application because there is no final application version. by that statement we will be in beta applications forever, as it seems there could always be endlessly new 'beta' improvements.

Ideally they should be called gamma... beta should be on Ralph but i'm not sure they're really using Ralph any more... so maybe beta is accurate for all rosetta WUs!

---

Ideally they should be called gamma... beta should be on Ralph but i'm not sure they're really using Ralph any more... so maybe beta is accurate for all rosetta WUs!

They darn sure aren't doing much testing on Ralph. Should be tested on a standard number of WUs (500?) on each of a wide range of platforms and clients before they throw it over the fence to here.

---

Proudly Banned from Predictator@Home and now Cosmology@home as well. Added SETI to the list today. Temporary ban only - so need to work harder :)



"You can't fix stupid" (Ron White)

So... no resolution here ? 5 of my cpu's have been out of service since Dec. 20

On line but unable to get any work units that can be processed in 256 MB on 2.6 Ghz intel hyperthreading processors. Too bad.

---

Think the minimum is now closer to 512 for 5.90 stuff, you should post a portion of your BOINC manager log to show what kind of message you are getting.
I have 512 and after the server outage I could not get any work for a few days.
But then it cleared up and I have lots of work again.

So... no resolution here ? 5 of my cpu's have been out of service since Dec. 20

On line but unable to get any work units that can be processed in 256 MB on 2.6 Ghz intel hyperthreading processors. Too bad.

---

So... no resolution here ? 5 of my cpu's have been out of service since Dec. 20

On line but unable to get any work units that can be processed in 256 MB on 2.6 Ghz intel hyperthreading processors. Too bad.

Since BOINC sees a Hyperthreaded CPU as a two core processor and crunches two work units at a time on it you really only have 128MB of memory per CPU so it does not meet minimum memory requirements.
You could turn off Hyperthreading in the bios and run it as a single core processor or get more memory.

So... no resolution here ? 5 of my cpu's have been out of service since Dec. 20

On line but unable to get any work units that can be processed in 256 MB on 2.6 Ghz intel hyperthreading processors. Too bad.

Since BOINC sees a Hyperthreaded CPU as a two core processor and crunches two work units at a time on it you really only have 128MB of memory per CPU so it does not meet minimum memory requirements.
You could turn off Hyperthreading in the bios and run it as a single core processor or get more memory.

rochester ny 3 has only 128mb and seems to be running ok

So... no resolution here ? 5 of my cpu's have been out of service since Dec. 20

On line but unable to get any work units that can be processed in 256 MB on 2.6 Ghz intel hyperthreading processors. Too bad.

Since BOINC sees a Hyperthreaded CPU as a two core processor and crunches two work units at a time on it you really only have 128MB of memory per CPU so it does not meet minimum memory requirements.
You could turn off Hyperthreading in the bios and run it as a single core processor or get more memory.

rochester ny 3 has only 128mb and seems to be running ok

jegs has plenty of work now after a few errors.
so whatever it was, it was just one of those Rosie errors that jams things up.

---

Status update:

Following suggestions posted here, I adjusted preferences to allow a max of one CPU. This indeed limited the scheduler to one task on hyper threaded machines. So far so good. I did encounter one anomaly when a task ( the only one running ) stalled and reported waiting for memory. I'm not sure where it thought it would get more. No limits set and system managed memory enabled. Hundreds of GB not enough ? I aborted the job an Boinc continued.

---

I did encounter one anomaly when a task ( the only one running ) stalled and reported waiting for memory. I'm not sure where it thought it would get more.

It is not about the amount of memory installed in your computer, it is about the amount of memory available to run the client. Depending on what other applications are currently running the amount of memory available to Boinc and project clients can indeed change.

Unfortunately the Rosetta client (at least on Linux, since that is all I'm using) still has problems with Boinc task switching which requires to keep the client in memory even if it is not active (this is an option in your Boinc preferences). Keeping the inactive (waiting to run) tasks in memory however reduces the amount of memory available to other Boinc tasks. This usually only affects users who participate in multiple Boinc projects since the Boinc client will not normally switch between tasks for the same project (exception is if a non-active workunit nears the project deadline).

---

Team Helix