ram, swap, and Multi-Directional Gravitational Wave search on O3
18 Feb 2023 19:49:47 UTC
Topic 229104
(moderation:
I have noticed that the Multi-Directional Gravitational Wave search on O3 projects use a lot of memory and swap ssd on an m1 Mac. I would like to keep this particular project from loading because of it. I have unchecked this project type in the settings in my Account -> Preferences -> Project tab, but they continue to load. I use local Computing Preferences (in the BOIC app) to set limits and determine how BOINC should run.
I really don't like the amount of ram and swap that is uses. I can't seem to properly adjust my local Computing Preferences in the BOINC app to limit how these projects run. I'm suspending any more project work until I can figure out how to keep these projects from loading. Einstein@home is the only BOINC project I run.
Is there anything else I need to do to keep the Multi-Directional Gravitational Wave search on O3 from running?
Thanks for any help and advice!
Tim
Verify which location or
)
Verify which location or venue the host is assigned.
Uncheck the GW03 cpu tasks in the Project Preferences for the venue the host is assigned.
In Boinc Manager Project, Select the Einstein project. Hit the Update button.
Done.
Hey Keith thanks! I
)
Hey Keith thanks! I apologize, but I don't know how to do the first two things. A step-by-step would be helpful. I've never had to do this with a project before. Normally I just set the cpu usage to 50% and everything is peachy. Thanks again if you have time to respond.
Tim
Edit: I think maybe if I use web-based preferences instead of local ones it may omit the O3 projects. I'll give it a try for a while and see how it goes.
chilina wrote: I have
)
Go back to that same page and scroll down below where you deselected that particular search to find another setting, "Allow non-preferred apps". Make sure that setting is set to 'No'.
The setting for 'location' is at the very top of the page where there is a drop-down box. If it shows the default 'generic' setting it probably means you are not using different locations so that is probably not the problem. Unless you need to manage different settings for multiple machines, you don't need to worry about locations. If you are using multiple locations, there is a "show comparison view" at the bottom of the page where you can list all the settings in a 'side by side' comparison table.
If you make any changes, don't forget to "Save".
Cheers,
Gary.
chilina wrote:Edit: I think
)
Using local prefs doesn't affect the selection of search apps. Local prefs are perfect for things like fine tuning the work cache size and number of cores the client is allowed to use, etc.
Cheers,
Gary.
Gary Roberts wrote: Local
)
Hey thanks Gary! This is helpful to know. I'm back to local preferences and I'll see if any more of the O3 projects download.
My m1 mini can handle one of these O3 projects, but 3 or 4 of them at once was too much for it with only 8gb of ram. This has been my first issue in like a decade of running BOINC projects. I'm glad that Einstein@home has an active forum, and I really appreciate your help!
chilina wrote:... I'll see if
)
Was the "Allow non-preferred apps" setting set to 'Yes'? If so, did you change it to 'No' with the O3 app still not selected? The GW search is preferred by the project and the scheduler will tend to send GW tasks if the opportunity exists. The scheduler seems to regard that setting on 'Yes' as an "opportunity" :-).
BOINC has a mechanism (using an app_config.xml file) for project level configuration that allows you to specify things like the maximum number of concurrent tasks for a particular search app. There have been issues with the use of max_concurrent with older BOINC versions. I notice you are using 7.20.4. If that's the latest version for macOSX you should be OK since the problem was supposed to be fixed recently.
The O3 app could be set to only ever run a single task at a time, if you set up an app_config.xml file. Read the instructions very carefully. It's all there but it can be a bit daunting for the uninitiated.
For example, the <name> you need to use is a short name and if the one I've used below is not correct you can find what it should be by looking at the <name> entry in your state file, client_state.xml. Be careful not to change anything in the state file while looking. You create the file with a plain text editor and put it in the Einstein project directory. There is a BOINC Manager option to 'reread config files' to start using it without restarting the client.
My hosts do GPU crunching and I use app_config.xml to run multiple tasks per GPU. I'm not running any O3MD1 CPU tasks so the following example of what you need to run a single CPU task is a bit of a guess. You would have the O3MD1 search and whatever other CPU searches you wanted all selected and limit O3MD1 to a single task by using:-
<app_config>
<app>
<name>einstein_O3MD1</name>
<max_concurrent>1</max_concurrent>
</app>
</app_config>
In addition to this, you would use the local pref for the total percent of processors that could be used if you wanted to run less than 8 total. For example, if you set that to 50%, you should get one O3MD1 task and a mix of 3 more from whatever other CPU searches you had allowed. I emphasise that it's a long time since I ran CPU searches so the above is a 'best guess' at what to try to start off with.
There would be others doing something like this so someone will comment if there's any mistake :-).
Cheers,
Gary.
The max_concurrent fetch
)
The max_concurrent fetch problem was fixed in the 7.20 branch back in December. From the release notes.
Changes in 7.20.0
Hey thanks for the link and
)
Hey thanks for the link and details on the xml file. Maybe just 1 more quick question: If I set up this xml file, will it persist if BOINC is updated, or does its folder get overwritten in an update? I would let 1 or 2 of them run at a time; the xml file is a nice solution!
The app_config.xml is
)
The app_config.xml is persistent. Usually stays put even with a BOINC reinstall as long as you don't manually remove the installation directories.
The recent batch of O3MD1
)
The recent batch of O3MD1 (cpu) tasks do seem to use more RAM than what I'm used to. I have two tasks currently running; one is using 1.8 GB resident RAM and the other one 3.2 GB. Enough RAM (16G) that there are no adverse side effects plus four BRP4G (cpu) tasks at 200 MB each. Temporarily no GPU tasks in the cache - internet service is in distress, giving me about 40 kb/s speeds and very "bursty" responses. I have no idea, of course, whether 3.2 GB is a "typical" size for the O3MD1 tasks. But if it is, then one can certainly understand some systems' RAM resources being overloaded. Solutions outlined earlier in this thread will work. I use the app_config.xml method myself.