LHC@home

The following is thought as an answer to PHILIPPE's questions but would be OT in the original thread.


Some explanations:
I spread my resources among different projects. CPU/GPU, LHC/non-LHC, VM-based/non-VM-based
I run a self made script that ensures my hosts are not overloaded. Therefore most of the time I use only 6 out of 8 cores for CPU apps, sometimes 5(4) cores, sometimes 7.
For a couple of reasons I run only 1 LHC app concurrently on each of my hosts, except for testing.
Among the LHC apps ATLAS is the most resource hungry app during runtime and the only one that is a native multicore app.
I noticed that if I set it up as a 2-core app (website, RAM, nthreads-parameter) and force my BOINC client to treat it as a 1-core (avg_ncpus=1) I get a better 6/7-core ratio from my client.


Based on this setup I treat other LHC VM-based subprojects also as 2-cores although I know that they are basically not.

Advantages:
- runtime is x/2 (ATLAS)
- they benefit from the better 6/7-core ratio
- they produce much more scientific output
- BOINC runs another project on the spare core if the LHC app uses only 1 core, e.g. during stage-in/out or if Theory runs a sherpa in one of the slots and leaves the other slot dry for hours and hours

Disadvantages:
- There is no credit reward for the 2nd core in LHC as it is not implemented on the server
- The VMs need more RAM


RAM setting

It's nearly impossible to give a clear advice without a close look into the running VM.
Every VM uses RAM for:
- the own OS
- some spare RAM
- the local disk cache
- cvmfs
- scientific apps

The RAM usage may be influenced by a couple of configuration parameters
- swappiness=xx influences the RAM distribution between disk cache and OS/apps
- cvmfs: I'm not sure if a lower RAM setting leads to more network activity, i.e. cvmfs would act like a proxy cache
- some apps (IIRC CMS multicore on the dev-project??) may check the amount of free RAM before they start additional jobs

To bring all points together I use again ATLAS as I noticed that it simply crashes if there is not enough RAM.
All other subprojects need less RAM and therefore I spend them more than probably necessary.

Nevertheless I notice huge variations in RAM/swap usage during runtime, especially on Theory VMs.

On hosts with very low RAM there is one general suggestion:
Test it.

Thanks to share your experience.
I know it is time consuming to answer accurately.

It's true that it is better to test by oneself because each case is different and you can't do it as your host seems to be very active and busy.

It's the reality of serious cruncher...

So i have followed your advice and have tried to sort arguments , with a little survey on theory wus.
I locate it in theory part forum because it mainly concerns this sub-project.
I can 't do the same for other sub-projects because i don't have enough ram memory.
But , why not someone else ?...ʕ•̫͡•ʕ*̫͡*ʕ•͓͡•ʔ-̫͡-ʕ•̫͡•ʔ*̫͡*