LHC@home

For those, that are used to work with an app_config, I just tested it here and it seems to work fine.

My preference is configured to use 2 Cores, my app_config.xml allows 4 Cores and I downloaded an 4-Core-WU.

For those that are interested:

<app_config>
 <project_max_concurrent>2</project_max_concurrent>
<app_version>
    <app_name>ATLAS</app_name>
    <version_num>100</version_num>
    <platform>windows_x86_64</platform>
    <avg_ncpus>4.000000</avg_ncpus>
    <max_ncpus>4.000000</max_ncpus>
    <plan_class>vbox64_mt_mcore_atlas</plan_class>
    <api_version>7.7.0</api_version>
    <cmdline>--memory_size_mb 7500</cmdline>
    <dont_throttle/>
    <is_wrapper/>
    <needs_network/>
</app_version>
</app_config>

Note, my memory-setting is higher as needed.

The latest formular for calculating memory size is 1,4 GB + (NumberOfCores) * 0,8 GB

so for a 4-Core-WU it is: 1,4 GB + 4*0,8 GB = 4,6 GB

---

Supporting BOINC, a great concept !

Hello Yeti,

Why do you place the following tags in your app_config.xml?

<version_num>100</version_num>
<platform>windows_x86_64</platform>
<max_ncpus>4.000000</max_ncpus>
<api_version>7.7.0</api_version>
<dont_throttle/>
<is_wrapper/>
<needs_network/>

According to the official BOINC documentation http://boinc.berkeley.edu/wiki/client_configuration#Application_configuration the app_config.xml has the following format/tags:

<app_config>
   [<app>
      <name>Application_Name</name>
      <max_concurrent>1</max_concurrent>
      [<fraction_done_exact/>]
      <gpu_versions>
          <gpu_usage>.5</gpu_usage>
          <cpu_usage>.4</cpu_usage>
      </gpu_versions>
    </app>]
   ...
   [<app_version>
       <app_name>Application_Name</app_name>
       [<plan_class>mt</plan_class>]
       [<avg_ncpus>x</avg_ncpus>]
       [<ngpus>x</ngpus>]
       [<cmdline>--nthreads 7</cmdline>]
   </app_version>]
   ...
   [<project_max_concurrent>N</project_max_concurrent>]
</app_config>

A view into the BOINC source code (app_config.cpp of version 7.6.31) shows that other tags will either be ignored or cause a warning message.

Hello Yeti,

Why do you place the following tags in your app_config.xml?

<version_num>100</version_num>
<platform>windows_x86_64</platform>
<max_ncpus>4.000000</max_ncpus>
<api_version>7.7.0</api_version>
<dont_throttle/>
<is_wrapper/>
<needs_network/>

A view into the BOINC source code (app_config.cpp of version 7.6.31) shows that other tags will either be ignored or cause a warning message.

HM, I copied the whole section from client_state.xml to avoid missing an important parameter.

As long as the BOINC-Client dosn't say unknown parameter I think all is fine

---

Supporting BOINC, a great concept !

HM, I copied the whole section from client_state.xml to avoid missing an important parameter.

As long as the BOINC-Client dosn't say unknown parameter I think all is fine

Hello Yeti,

I agree with computezrmle to use only the needed parameters in the app_config.xml to avoid confusing by other crunchers.

The app_version part of the xml for ATLAS only needs:

 <app_version>
  <app_name>ATLAS</app_name>
  <plan_class>vbox64_mt_mcore_atlas</plan_class>
  <avg_ncpus>4.000000</avg_ncpus>
  <cmdline>--memory_size_mb 4600</cmdline>
 </app_version>

One could add the line <cmdline>--nthreads 4.000000</cmdline>
but with the <avg_ncpus> also the right cored VM is created and let BOINC know to reserve 4 cores for the task.

Can i change the number of CPU-cores used whitin a wu on app_config, on middle of a task without killing it?

---

Can i change the number of CPU-cores used whitin a wu on app_config, on middle of a task without killing it?

This might technically be possible although not by just changing the app_config.xml.
Nonetheless it is not recommended for the following reasons:

1.
The server planned your tasks according to the settings when work has been requested.
Hence a task requested as 2-core task would remain a 2-core task from your BOINC client's perspective.

2.
A task that has already set up it's worker threads inside the VM would continue running the same worker threads after the resume.
It would not add nor cancel any threads.


It is recommended to set your client to NNT (No New Tasks) and wait until all work is done.
Then change the setup and finally request fresh work.