app_config.xml: max_concurrent ignored?

cecht
cecht
Joined: 7 Mar 18
Posts: 1,509
Credit: 2,802,987,164
RAC: 2,161,362
Topic 219535

Using the app_config.xml shown below, my Linux host with two AMD GPUs and a 4-core CPU had been running, as expected, 6 tasks with the Gamma-ray pulsar binary search #1 on GPUs v1.18 application and 2 tasks with the Continuous Gravitational Wave search O2 All-Sky v1.01application (a.k.a. GW CPU). (Current Project Preferences are set to not run beta test applications, so no O2AS20-500 v1.07 GPU work):


<app_config>
  <app>
    <name>hsgamma_FGRPB1G</name>
    <fraction_done_exact/>
    <gpu_versions>
      <gpu_usage>0.333</gpu_usage>
      <cpu_usage>0.4</cpu_usage>
    </gpu_versions>
  </app>
  <app>
    <name>einstein_O2AS20-500</name>
    <fraction_done_exact/>
    <gpu_versions>
      <gpu_usage>0.33</gpu_usage>
      <cpu_usage>0.4</cpu_usage>
    </gpu_versions>
  </app>
  <app_version>
    <app_name>einstein_O2AS20-500</app_name>
    <plan_class>LIBC215</plan_class>
    <avg_ncpus>0.7</avg_ncpus>
    <max_concurrent>2</max_concurrent>
  </app_version>
<project_max_concurrent>8</project_max_concurrent>
</app_config>

When the following mysterious, but transient, error popped up in my Event Log: "platform 'x86_64-pc-linux-gnu' not found", the host stopped getting downloads of the GPU tasks. (The error initiated a 24 hr backoff, but when I prompted a project update a few hours into the backoff, it began downloading GPU tasks again and tasks ran as expected.) But before things returned to normal, when the FGRPB1G GPU queue ran out, BOINC began running five concurrent GW CPU tasks. With how app_config is set up, I expected it to just continue running two concurrent GW CPU tasks.

So why did the <max_concurrent>2</max_concurrent> setting for O2AS20-500 CPU work not hold in the absence of FGRPB1G GPU work? And why five concurrent CPU tasks and not eight? Was it because that's all that could fit onto 4 cores with <avg_ncpus>0.7</avg_ncpus>?

Ideas are not fixed, nor should they be; we live in model-dependent reality.

Zalster
Zalster
Joined: 26 Nov 13
Posts: 3,117
Credit: 4,050,672,230
RAC: 0

Why do you have a plan class

Why do you have a plan class in there?

Harri Liljeroos
Harri Liljeroos
Joined: 10 Dec 05
Posts: 4,192
Credit: 3,113,100,392
RAC: 1,833,336

The

The <max_concurrent></max_concurrent> setting goes between <app></app> tags, not <app_version></app_version> tags.

See https://boinc.berkeley.edu/wiki/Client_configuration

cecht
cecht
Joined: 7 Mar 18
Posts: 1,509
Credit: 2,802,987,164
RAC: 2,161,362

Harri Liljeroos wrote:The

Harri Liljeroos wrote:

The <max_concurrent></max_concurrent> setting goes between <app></app> tags, not <app_version></app_version> tags.

See https://boinc.berkeley.edu/wiki/Client_configuration

Ah. Yes, I see. Thanks. That explains some things. The number of GW CPU tasks (2) was determined by the <project_max_concurrent> (8 - 6 = 2); having <max_concurrent> in <app_version> wasn't doing anything.

Zalster wrote:
Why do you have a plan class in there?

I had wanted to have different cpu parameters for the beta GW GPU app(s) and the GW CPU v1.01(plan class LIBC215) app without having to edit app_config each time I switch Project preferences to run one app or the other.

EDIT: But I now see that that is unnecessary because <cpu_usage> takes care of it under <gpu_versions> for the GW GPU app; for the GW CPU app, I can get by just fine with the default <avg_ncpus> of 1 and so don't need <app_version> at all.  As usual, I was making things too complicated. :(

Thank you all for making me actually think about what I was doing. :)

Ideas are not fixed, nor should they be; we live in model-dependent reality.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.