purpose of XMLs: global_prefs and global_prefs_override on "leave apps in memory"

Message boards : BOINC client : purpose of XMLs: global_prefs and global_prefs_override on "leave apps in memory"
Message board moderation

To post messages, you must log in.

AuthorMessage
Profile Joseph Stateson
Volunteer tester
Avatar

Send message
Joined: 27 Jun 08
Posts: 641
United States
Message 96313 - Posted: 3 Mar 2020, 15:01:15 UTC
Last modified: 3 Mar 2020, 15:06:40 UTC

Never paid much attention to any of those files. They show up during an install of boinc.
My "global_prefs.xml" is from WCG. Just looked at 4 Linux systems and one windows. They are all from WCG and I assume the rest of my "farm" also have WCG as the default source for parameters in global_prefs.xml. The first project I ever signed up for was SETI so unsure of how WCG got the default.

LHC at home has a warning that it does not checkpoint multi-core apps and recommends they be left in memory when restarting boinc. This applies only to Linux systems, and I was unaware of this until after I restarted boinc. It seems that the tasks resided in memory as the times did not get reset to 0 so I got to looking at why there were not reset.
jstateson@jysdualxeon:/var/lib/boinc$ grep "leave_apps" *.xml
global_prefs_override.xml:   <leave_apps_in_memory>0</leave_apps_in_memory>
global_prefs.xml:  <leave_apps_in_memory>0</leave_apps_in_memory>
global_prefs.xml:    <leave_apps_in_memory>1</leave_apps_in_memory>
global_prefs.xml:    <leave_apps_in_memory>1</leave_apps_in_memory>
global_prefs.xml:    <leave_apps_in_memory>0</leave_apps_in_memory>
sched_request_einstein.phys.uwm.edu.xml:   <leave_apps_in_memory>0</leave_apps_in_memory>
sched_request_einstein.phys.uwm.edu.xml:  <leave_apps_in_memory>0</leave_apps_in_memory>
sched_request_einstein.phys.uwm.edu.xml:    <leave_apps_in_memory>1</leave_apps_in_memory>
sched_request_einstein.phys.uwm.edu.xml:    <leave_apps_in_memory>1</leave_apps_in_memory>
sched_request_einstein.phys.uwm.edu.xml:    <leave_apps_in_memory>0</leave_apps_in_memory>
sched_request_lhcathome.cern.ch_lhcathome.xml:   <leave_apps_in_memory>0</leave_apps_in_memory>
sched_request_lhcathome.cern.ch_lhcathome.xml:  <leave_apps_in_memory>0</leave_apps_in_memory>
sched_request_lhcathome.cern.ch_lhcathome.xml:    <leave_apps_in_memory>1</leave_apps_in_memory>
sched_request_lhcathome.cern.ch_lhcathome.xml:    <leave_apps_in_memory>1</leave_apps_in_memory>
sched_request_lhcathome.cern.ch_lhcathome.xml:    <leave_apps_in_memory>0</leave_apps_in_memory>
sched_request_milkyway.cs.rpi.edu_milkyway.xml:   <leave_apps_in_memory>0</leave_apps_in_memory>
sched_request_milkyway.cs.rpi.edu_milkyway.xml:  <leave_apps_in_memory>0</leave_apps_in_memory>
sched_request_milkyway.cs.rpi.edu_milkyway.xml:    <leave_apps_in_memory>1</leave_apps_in_memory>
sched_request_milkyway.cs.rpi.edu_milkyway.xml:    <leave_apps_in_memory>1</leave_apps_in_memory>
sched_request_milkyway.cs.rpi.edu_milkyway.xml:    <leave_apps_in_memory>0</leave_apps_in_memory>
sched_request_www.worldcommunitygrid.org.xml:   <leave_apps_in_memory>0</leave_apps_in_memory>
sched_request_www.worldcommunitygrid.org.xml:  <leave_apps_in_memory>0</leave_apps_in_memory>
sched_request_www.worldcommunitygrid.org.xml:    <leave_apps_in_memory>1</leave_apps_in_memory>
sched_request_www.worldcommunitygrid.org.xml:    <leave_apps_in_memory>1</leave_apps_in_memory>
sched_request_www.worldcommunitygrid.org.xml:    <leave_apps_in_memory>0</leave_apps_in_memory>


From the above it looks like the default WCG caused all projects to have the same parameters
(global),generic, home, school, work respectively (0),0,1,1,0 for "leave apps in memory"
I recall going to WCG and setting the 0,1,1,0 so can I assume that caused all the other projects to get set the same way ?
Looking at the "override" which shows "0" and reading this
https://boinc.berkeley.edu/trac/wiki/PrefsOverride
It appears that the override in not applied automatically as an RPC call needs to be made to force it. Is that correct?

What is strange is that the Atlas app was "generic" venue and that was "0" in all of the above so it should have started from scratch but it seems to have been left in memory and picked up where it left off which is OK with me. OTOH, the project may have implemented checkpoint and didn't bother to update the warning.

If the venue is "work" and a "work" app is running on project X, and that venue requires the app be left in memory, I assume that BOINC will only leave that app in memory and not other venues or other project apps.
ID: 96313 · Report as offensive
Profile Jord
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 29 Aug 05
Posts: 15480
Netherlands
Message 96320 - Posted: 3 Mar 2020, 15:50:16 UTC - in response to Message 96313.  

For both the local preferences (_override) and web preferences Activity needs to be set to "Run based on preferences", as "Run always" will ignore preferences.
The purpose of the leave_apps_in_memory switch is exactly that, to leave applications in main memory when BOINC suspends computations.
When BOINC exits, of course any application still running or suspended will exit as well.

The last project that you set the web preferences at will show as the place those preferences were set at, even if they're not used due to use of local preferences.
Preferences are read via scheduler contact and distributed in that way to all other projects using that same location or venue.
ID: 96320 · Report as offensive
Profile Dave
Help desk expert

Send message
Joined: 28 Jun 10
Posts: 2533
United Kingdom
Message 96325 - Posted: 3 Mar 2020, 16:18:23 UTC - in response to Message 96320.  

For both the local preferences (_override) and web preferences Activity needs to be set to "Run based on preferences", as "Run always" will ignore preferences.
The purpose of the leave_apps_in_memory switch is exactly that, to leave applications in main memory when BOINC suspends computations.
When BOINC exits, of course any application still running or suspended will exit as well.

The last project that you set the web preferences at will show as the place those preferences were set at, even if they're not used due to use of local preferences.
Preferences are read via scheduler contact and distributed in that way to all other projects using that same location or venue.


I don't know if it is true for other projects as well but ticking the Leave non-gpu tasks in memory while suspended, in my experience and others' at least with CPDN reduces the number of tasks that crash. At some point I am sure someone explained why but I can't remember the reason now.
ID: 96325 · Report as offensive
ProDigit

Send message
Joined: 8 Nov 19
Posts: 718
United States
Message 96499 - Posted: 8 Mar 2020, 13:36:55 UTC

I would presume it'll just continue tasks from a paused state better.
If they're not in memory, they'll have to reload to the last savestate, which means you'll lose a few %.
On powerful GPUs running small (~5min) tasks, the feat is pretty useless.
On larger tasks, running slower hardware it may help some.
On either systems with low memory, or systems with a lot of GPU/CPUs, it might not be the best thing to keep enabled.
ID: 96499 · Report as offensive

Message boards : BOINC client : purpose of XMLs: global_prefs and global_prefs_override on "leave apps in memory"

Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.