It also says "Mesage from server: Your preferences limit memory usage to 460.16MB and a job requires 476.84MB". Now 2 of my computers can no longer process any work. I must have changed a setting but I can't figure it out. All of a sudden today I am getting this message from Rosetta. I have not had a problem in the past with Rosetta. Can someone tell me how to set the prefences back to default so Rosetta will download more work please?

---

Umm... if you don't have enough RAM in your computer then you can't download work until Rosetta supplies work with a lower minimum requirement.

---

Umm... if you don't have enough RAM in your computer then you can't download work until Rosetta supplies work with a lower minimum requirement.

As I stated in my first post I thought I might have made some changes that could have caused this. I guess there will be no work to be done on these 2 computers...

Strange thing is I have not had a problem with Rosetta on either of these computers before. Granted I have only been running them for about a month or so. Oh well. Thanks for the reply.

---

Just leave BOINC as it is - when there is more work with a lower RAM requirement your computers will automatically get it.

If you have migrated to BOINC version 5.8 or above then there are a number of new preference settings. One of them is:

Use at most 90% of memory when computer is idle. Enforced by version 5.8 and greater

If your machine has 512MB of Memory then this setting will, in effect, reduce the available memory for BOINC to about 460 MB ... which is less than required for some of the Rosetta work units.

The solution is to modify the preference settings.

---

04/03/2007 09:11:41|rosetta@home|Message from server: Your computer has 255.48MB of memory, and a job requires 476.84MB
04/03/2007 09:11:41|rosetta@home|Message from server: No work sent
04/03/2007 09:11:41|rosetta@home|Message from server: (there was work but your computer doesn't have enough memory)

https://boinc.bakerlab.org/rosetta/rah_requirements.php

?

---

There is a BOINC issue here. (Skip to the nextpost if you just want advice.)

The amount of memory needed by a task is not what is being measured, but the amount of memory in the computer.

The reason this is a problem is that an app (say Ros 5.48) needs the computer to have (say) 450 Mb RAM when running alongside Win XP or KDE, but that same app might need the computer to have only 200Mb when running alongside Linux without a GUI.

Another aspect of this is graphics. A user who wants to see the Rosetta gfx will need more memory to run Rosetta than another user (Linux no GUI again) who does not have any gfx capability and for whom therefore the Rosetta app never loads any of the gfx code.

The solutions need all of the following:

1. Project admins to set memory demands for the task itself, not their estimate of the amount of memory needed by the computer

2. Default %required to be set for the 'majority' user, ie at present for Win XP, soon maybe for Vista so that Windows does not lock up when the task is running

3. Users whose setup does not conform to the majority should set much higher %available both while they are working and while the box is idle


In the longer run, it is probably a mistake, in my opinion, to set these as percentages. The amount required for other tasks should be a fixed number not a percent. So, in my opinion, the prefs should read

Leave at least ____ Mb for operating system and non-BOINC work when computer is in use

Leave at least ____ Mb for operating system when computer is idle

Then the magic values could be found for each operating system and users advised accordingly. It seems obvious tome that Win XP will need about the same absolute amount of memory reserved for itself to prevent it going sluggish regardless of whether the box has 256MB or 8GB installed.

This matters because there is no sensible % that will work for a mix of boxes that span 256Mb to 4Gb all running the same OS. There are only 3 or 4 allowed 'venues' and users may already have used them all up to make other distinctions between machines. A 'leave at least' regime is more likely to apply acorss a range of machines that a % based one.

But this is a BOINC issue. Feel free to re-post my remarks on the BOINC forums if you agree with me on this (I am not using them at present so will not be posting it myself)

What this project can do is for the admins to take point 1 on board, and for admins and/or other experts to post suitable advice on settings that seem to work.

R~~

... Can someone tell me how to set the prefences back to default so Rosetta will download more work please? ...

Just to clarify, it is not a case of setting the prefs back to default, nor is it the change in Rosetta version that has done this - it is the change in BOINC version. The prefs were ignored before, and the problem arises because as soon as you installed the latest BOINC it started to apply them - so it is probably applying the defaults.

Go into General prefs (if you are multi project, do this on whatever project you usually use to set prefs, they will propagate across to all other projects).

Find the new entries in the table "Use at most ____% of memory when computer is in use" and "... when computer is idle", and put in numbers to suit. 100% will mean that projects are free to use all of available RAM, menaing that you are not protected from memory-induced sluggishness. I have set 99% for both.

I don't know if it accepts numbers > 100%, but if it does accept them and take them literally, then setting a number >100% would mean you can use the swapfile to run a task that is nominally too big. This would have a perfomrance hit on the processing of the Rosetta (or other project) work, as indeed happened prior to BOINC version 5.8 if you got work that was too big for your memory.

Hope that helps and enlightens
R~~

---

I'm getting the same error, having not changed any settings or the BOINC version.

I'll follow your suggestion and change both memory limits to 95% or something - also, I understand Matt's suggestion that the admins need to release some jobs that run in 256MB.

Until then, 3 of my 6 machines are idle...

---

Alver Valley Software Ltd - Contributing ALL our spare computing power to BOINC, 24x365.

... also, I understand Matt's suggestion that the admins need to release some jobs that run in 256MB.

Until then, 3 of my 6 machines are idle...

please please please pretty please,

run another project at a low resource share (eg resource share = 1 with Rosetta share = 100). This will make almost no impact on your Rosetta results over a period of time, but will mean your box is not idle if Rosetta is unavailable for any reason.

Of course, with the new regime, that could still happen if both/all projects were asking for > 256Mb...

R~~

Rosetta is one of the project which has the biggest memory requirement.
It's pitty because rosetta is the best BOINC project with one of the best communication. :(

---

Rosetta is one of the project which has the biggest memory requirement.

Very true, but how much of this is needed by the science and how much by the graphics?

I have never seen much swapfile usage on Rosetta, even on my boxes that have only 256Mb mem, but no graphics. If I am right (and, for example, if the programmers have not recently added 100% to the size of the code) then the scheduler is preventing me from downloading work which wouyld actually run without problems.

For example right now I have a CPDN and a Rosetta both sharing just 256M RAM, and the swapfile usage is only up to 2M. (Linux, no GUI, no graphics, not even X)

R~~

---

I agree with you.

[quote]For example right now I have a CPDN and a Rosetta both sharing just 256M RAM, and the swapfile usage is only up to 2M. (Linux, no GUI, no graphics, not even X)[quote]
But linux doesn't use 60% of the memory without any program. =D

---

An additional strategy, if your machine has an integrated video controller,is to change the BIOS settings and reduce the amount of shared memory allocated to video to 16MB or so. This will, in effect, increase the amount of memory that BOINC sees and allocates to Rosetta.

This won't be very useful for machines with 256MB of memory but might be helpful for 512MB machines that are right on the edge in terms of available memory for Rosetta.

---

I'm getting the same error, having not changed any settings or the BOINC version.

I'll follow your suggestion and change both memory limits to 95% or something - also, I understand Matt's suggestion that the admins need to release some jobs that run in 256MB.

Until then, 3 of my 6 machines are idle...

This is why I have always had two or more projects on my three boxes. Rosetta still gets by far the lions share though, but you never know when rosy will be down or out of action for awhile. I would recommend one of the other protein prediction projects: Proteins and Predictor (both in advanced beta and going live lickety split, so problems here are few if any), and Docking (still alpha). They don't all do the same thing, of course, but there is lots of overlap to be comfortable with if you like rosy like I do.

---

(Click for detailed stats)

DO NOT DISPAIR! I, too, suddenly got this message for the first time, so I tried tweaking my general preferences. I increased the memory available from 50% to 60%, but this produced no change. I increased the swap file setting from 75% to 80%. No change. Did they mean the disc space, I wondered. So I increased this from 50% to 60%. No change.
Then I increased the idle time memory setting from 90% to 95%, and hey presto, down came a fresh unit. But it has the same completion time as the others in my cache. Hmm.

--

BTW... Only the HINGE_* WU's are set to 478MB required... They are actually using 390MB... so this is not a BOINC issue, but, an issue of a parameter set for this particular class of WU....

---

Looking for a team ??? Join BoincSynergy!!

--

BTW... Only the HINGE_* WU's are set to 478MB required... They are actually using 390MB... so this is not a BOINC issue, but, an issue of a parameter set for this particular class of WU....

I think this supports my view, or at least might do.

I notice that all your boxes are Linuces of various flavours. My furst guess is not that the Rosetta folk got the numbers wrong, but that they have fed in the numbers for the majority platform, Win-XP, and that BOINC offers no way to make the Linux offering 88MB smaller.

Also, as a matter of interest, do you have graphics enabled on the box that shows a 390MB usage (eg Gnome/KDE plus X, etc) ? Did you look at the size only before displaying graphics, or both during and after displaying graphics?

Finally, it is however reassuring to know that other work units are not so big.

River~~

R~~
This is relevant because my second guess is that the size reflects a user who views the Rosetta graphics, and clearly memory will be saved when this is not done, because the relevant .so or .dll libraries will not be loaded.

--

BTW... Only the HINGE_* WU's are set to 478MB required... They are actually using 390MB... so this is not a BOINC issue, but, an issue of a parameter set for this particular class of WU....

I think this supports my view, or at least might do.

I notice that all your boxes are Linuces of various flavours. My furst guess is not that the Rosetta folk got the numbers wrong, but that they have fed in the numbers for the majority platform, Win-XP, and that BOINC offers no way to make the Linux offering 88MB smaller.

Also, as a matter of interest, do you have graphics enabled on the box that shows a 390MB usage (eg Gnome/KDE plus X, etc) ? Did you look at the size only before displaying graphics, or both during and after displaying graphics?

Finally, it is however reassuring to know that other work units are not so big.

River~~

R~~
This is relevant because my second guess is that the size reflects a user who views the Rosetta graphics, and clearly memory will be saved when this is not done, because the relevant .so or .dll libraries will not be loaded.

To determine the memory usage I used top... It uses the kernel tables to determine what is what...

None of my machines are graphics loaded.. too much much work for too little return.. I suppose my workstation is the exception, but, I never use the graphics anyway... (crunch..crunch..crunch...)

And, yes, the rest of your observations are likely relevent and correct,,,

---

Looking for a team ??? Join BoincSynergy!!

I don't know if it accepts numbers > 100%, but if it does accept them and take them literally, then setting a number >100% would mean you can use the swapfile to run a task that is nominally too big.

I tried setting memory usage to 120%, but it limited it to 100% when I saved the settings.