LHC@home

Run native if available?
is now in Atlas-Prefs. Do we need to activate it now?
Is the Beta-Pref obsolet?

I haven't enabled this for ATLAS yet, am waiting for the green light.

Run native if available?
is now in Atlas-Prefs. Do we need to activate it now?
Is the Beta-Pref obsolet?

Max 1 CPU, Max 1 Job => 1 single threaded job
Max 2 CPU, Max 1 Job => 2 threaded job 
Max 1 CPU, Max 2 Job => 1 single threaded job
Max 2 CPU, Max 2 Job => 2 x 2 threaded jobs

• As nthreads is set after the job has been sent out via the scheduler, this value is not taken into consideration when assigning credit
  
• Prefer to set it via the Web page rather than editing XML
  

Since the recent changes to Theory, this mainly affects that ATLAS application as setting Max # CPU is only relevant for that application.

Further comments welcome.

One of the reasons why Max#CPUs has been introduced was to simplify the ATLAS multicore configuration for users who didn't want to deal with an app_config.xml

When a workunit is sent to the client via scheduler reply it includes an <app_version> section and within this section <avg_ncpus> is set.
The client copies this <avg_ncpus> value to it's client_state.xml but overwrites it with the value from app_config.xml.
From now on the client as well as the vboxwrapper use the value that has been set last.

Unfortunately <avg_ncpus> is never reported back to the server via scheduler request.
It's in the user's responsibility to keep the values in sync.

If server and client are not in sync this affects credit calculation as well as the amount of work the server will send in future requests (at least until the FLOPS value is adjusted).

If Max#CPUs will be deactivated, every workunit will be treated as singlecore on the server, even ATLAS.
Not a problem for other apps since all of them are now singlecore but ATLAS may require a reworked default policy, e.g. a singlecore default combined with a new method to identify if the client runs tasks with n threads.

My suggestion would be therefore to disable the Max # CPU functionality and control it with the app_config.xml. Comments?

There is one big BUT.
When using only single core from server perspective, BOINC credit will calculate and grant credit based on the elapsed time times reported GFLOPS.
When a user setup VM's as dual, quadcore whatever by using app_config.xml, the elapsed time will reduce and his credit will be significant lower.
A lot of crunchers will not appreciate that.
We know that only ATLAS real benefits from multi-core. As long as ATLAS tasks are rather equal one could change to fixed credit / task for ATLAS.

native Theory(300.02) and native-Atlas(2.73) get only ONE Task for me.
native Theory(1.01) got two tasks with allways ONE Cpu in use.
Had nothing changed in prefs or app_config.

This will affect all VBox apps. I will investigate how to disable Max # of CPUs for single threaded apps.

I believe the relevant line is here. I don't think we can just disable this as it is used for ATLAS and CMS to select the number of CPUs to use for a VM so there needs to be an AND statement with something where that something is essentially !Theory.

<app_config>
   <app_version>
       <app_name>ATLAS</app_name>
       <plan_class>vbox64_mt_mcore_atlas</plan_class>
       <avg_ncpus>x</avg_ncpus>
   </app_version>
</app_config>

<app_config>
   <app_version>
       <app_name>ATLAS</app_name>
       <plan_class>vbox64_mt_mcore_atlas</plan_class>
       <cmdline>--nthreads 7</cmdline>
   </app_version>]
</app_config>

This will affect all VBox apps. I will investigate how to disable Max # of CPUs for single threaded apps.

I set Max jobs = 2 and Max CPUs 2 and ended up with two jobs each using 2 CPUs. Not sure this is what we want. The plan class currently contains:

    <min_ncpus>1</min_ncpus>
    <max_threads>2</max_threads>

As far as I understand the Theory app does use two threads but is there any advantage of giving two CPUs?

This is how limits are now working when requesting Theory's:

Max 1 task / thread
Max # of CPUs
Max # of jobs.

Since the tasks will run single core it's best to set 'No limit' for Max # of CPU's to avoid getting less tasks than you expect.
If you want less tasks than the number of threads set that lower value to Max # of tasks.

The first rig had 75 folders (most empty) in /slots/ and the first runRivet.log I found has 6,022 lines in it. I scrolled though them and see nothing that tells me anything.

The Max # CPUs is limiting the Max # of jobs.
Now max CPUs must be equal or higher than Max jobs, else you don't get the number of tasks you want or your buffer can hold.

E.g. Max # jobs 3
Max # CPUs 2

I only get 2 tasks. When I set Max # CPUs to 3 or higher, I get 3 tasks.

The Max # CPU's should have no influence on the number of tasks.

Btw: For Theory I would remove the Max # of CPUs and run only single core Theory-tasks.
At the moment higher number of cpus is only useful for the ATLAS-application.

    <min_ncpus>1</min_ncpus>
    <max_threads>2</max_threads>

I have a dozen or so nT 1.01 WUs that are running over 2 days. The CPU usage is jumping around in the 40-60%. Will these ever converge on a solution or should I Abort them???

Found this thread, is it this pref:
<max_wus_in_progress> N </max_wus_in_progress>
https://boinc.berkeley.edu/forum_thread.php?id=12588

Need to find out why njobs isn't as expected. It could be something trivial such as total_limit not being defined so defaulting to 1.

It looks like <per_proc/> is only used as a closing tag (when present) and not with a number in between like yours <per_proc>1</per_proc>

[quota] Limits for Theory:
[quota] CPU: base 1 scaled 7 njobs 0