Plan Class in app_info

[Ghost0210]

Hi all,
Have a question thats been bugging me for a while....

In our app_info's we always specify a plan_class, (cuda_fermi, ati13ati etc), question I have is why?

Been doing a bit of playing and it would seem that you can pretty much set the plan_class to be whatever you want. For example I'm using ati13ati @ Seti and ati13ati_beta @ Beta. This seems to cause no issues for work fetch/scheduling as far as I can see.
I'm still getting tasks and they process correctly, so why do we include this tag in the app_info?

I'm using different plan_class values at Seti & Beta purely as an easy way to differentiate between the two projects in the result section of the client_state. It seems to me that the coproc tag specifies which processor to use and all other tags are relatively self-explanatory except this one which doesn't seem to do a lot.
Other than my use for tag is there a purpose that I'm overlooking for the plan_class tag?

[Jason G]

Other than my use for tag is there a purpose that I'm overlooking for the plan_class tag?

Nope, in essence it's just a name for display, and I've done that myself in the past, so change away 

for each science application you have:
application name: e.g. setiathome_enhanced    <- high importance
version: e.g. 6.10  <- Little or no importance, but can be used to include multiple executables for an application & cover migration of existing, older marked tasks.
plan_class: e.g. cuda_fermi <- not important other than you might want work tagged differently for display, that's usually the case with GPU work
coprocs section etc <- High importance, determines the kind of work asked for & sent

So you can change the plan class names to what you want, but in the previous installer releases I found it helpful to stick as close as I could to the familiar .. Though that isn't required & I've passed installer work into other capable hands that may decide to change that sort of thing.

 

[Ghost0210]

Thanks Jason,

That's pretty much what I thought.
I've been playing with my app_info to see what could be changed without any major impact on work fetch etc, and both the plan_class and version_num tag have had no impact (don't play with the coproc section though bad things happen when you do  )

Ghost

[Richard Haselgrove]

.... I've passed installer work into other capable hands that may decide to change that sort of thing.

Speaking as the inheritor of that particular baton....

There are two quite separate and distinct questions:

1) What you can get away with in the privacy of your own host
2) What you can get away with without howls of protest when you're messing with other people's machines (e.g. via an installer )

An app_info file tells your computer how to process a task. For the app_info to work with any given task, no fewer than four elements have to match:

a) application name
b) platform
c) plan_class
d) version_num

If you start from a clean slate, with no tasks to process, you've got pretty much a free choice. As Jason says, the application name is crucial. And the coproc, if specified, can only be CUDA or ATI (or blank - none specified - for CPU). When it downloads work, BOINC will fill in platform, plan_class and version num to suit available entries in your app_info. And with those matching values, it'll work.

The problem arises when you want to change applications with downloaded work already present on the machine - and you don't want to lose it. That's when you need to be careful  that the *new* app_info covers all four bases for your existing work. The commonest situation is where a host starts off unoptimised - thus getting work with the 'set of four' assigned by the project for stock applications. To preserve that work (and avoid pissing-off first time optimisers), it makes sense for the Lunatics installer to follow - extremely closely - the precedents set by the project.

[Ghost0210]

Thanks Richard,

Basically I had a coouple of scenario's in mind at the moment that I wanted to test:

     1. Minimal app_info - remove all tags that weren't absolutely required or did very little to reduce the info that it held
          - Removing tags such as plan_class/version_num from the app_info until everything stopped working (from an empty cache)
            However, it seems that these tags must exist
     2. What values would be accepted by Boinc as being valid (Jason had already advised anything goes pretty much - again from an empty host)

I agree for mass consumption the installer should follow the projects precedents, I was just wondering and testing how much of the data pulled from the app_info is just for display purposes and how much actually had another purpose

[Richard Haselgrove]

I suggest you do your experimenting with a copy of the Anonymous Platform documentation at hand, and be prepared to contradict it - I have a Wiki editing account if needed.

It looks as if pretty much everything is optional, but the dependencies are unclear. I think if you have a <coproc>, you pretty much have to have a <plan_class> as well, but the reverse isn't true - you can have a <plan_class> without a <coproc> for CPU apps.

[Ghost0210]

Thanks for the link, was looking for that page this morning.
Once I've cleared my cache down on my main machine I'll start having a play and see if I can figure out the dependancies and whats optional and whats not

[Ghost0210]

So, found the major drawback in removing most of the tags that don't relate to files (version_num, plan_class, count, max/avg_ncpus)
Boinc appears to triy to run GPU tasks on both the CPU and GPU at the same time
Downloaded 6 ATI tasks (only requested ATI app_info had no other entry) with just the type tag set to ATI.
Straight away 3 * CPU tasks stopped running and 3 ATI tasks started running, using both a GPU slot and a CPU slot
Added in the count tag and 5 * CPU taks started runnng and 1 * ATI task
In my tasks page @ Seti it also shows that I downloaded 6 * CPU tasks (although GPU-Z was showing activity on the ATI card and Task Manager was showing reduced activity on the CPU)

So although it would seem that the plan_class and version_num tag are there just for display purposes in Boincmgr, it would seem that they also have a hand in deciding which device to use somehow.

[Richard Haselgrove]

Doesn't that documentation I referred you to suggest that the <coproc> block has to be unitary:

Code: [Select]

    [
      <coproc>
          <type>CUDA</type>
          <count>1</count>
      </coproc>
    ]
- in other words, if a <coproc> is present, it has to include both a <type> tag and a <count> tag? On the other hand, a <type> tag outside a <coproc> block would be meaningless and (probably) ignored? What does your startup message log say, with or without an <unparsed_xml> debug log flag?

[Ghost0210]

Doesn't that documentation I referred you to suggest that the <coproc> block has to be unitary:

Code: [Select]

    [
      <coproc>
          <type>CUDA</type>
          <count>1</count>
      </coproc>
    ]
- in other words, if a <coproc> is present, it has to include both a <type> tag and a <count> tag? On the other hand, a <type> tag outside a <coproc> block would be meaningless and (probably) ignored? What does your startup message log say, with or without an <unparsed_xml> debug log flag?

Absolutely, the FAQ does indicate that if the <coproc> tag is present then it must have both the <type> and the <count> child tags present as well.
The reason for me removing this tag was purely to see how Boinc would behave if it wasn't explicitly told how to behave in this scenario. i.e. would it default to running multiple tasks (as cpu tasks would) or would it run 1 task (only 1 compute device present for the ATI card)

There were no error messages in the startup log to indicate that there was a problem with either the app_info or the client_state (once it had read the app_info) - Here's an extract of the client_state app_version segment:

Code: [Select]

<app_version>
    <app_name>setiathome_enhanced</app_name>
    <version_num>0</version_num>
    <platform>windows_intelx86</platform>
    <avg_ncpus>1.000000</avg_ncpus>
    <max_ncpus>1.000000</max_ncpus>
    <flops>2611391213.695610</flops>
    <cmdline>-period_iterations_num 2 -instances_per_device 1 -hp</cmdline>
    <file_ref>
        <file_name>MB_6.10_win_SSE3_ATI_HD5_r177.exe</file_name>
        <main_program/>
    </file_ref>
    <file_ref>
        <file_name>MultiBeam_Kernels.cl</file_name>
        <copy_file/>
    </file_ref>
</app_version>
This segment explains why Boinc tried to run the task on the CPU and why the task page @ Seti shows CPU tasks as being downloaded - there's no <coproc> segement being written to the client_state although the coproc and type tags are in the app_info:

Code: [Select]

<app>
<name>setiathome_enhanced</name>
</app>
<file_info>
<name>MB_6.10_win_SSE3_ATI_HD5_r177.exe</name>
<executable/>
</file_info>
<file_info>
<name>MultiBeam_Kernels.cl</name>
<executable/>
</file_info>
<app_version>
<app_name>setiathome_enhanced</app_name>
<platform>windows_intelx86</platform>
<cmdline>-period_iterations_num 2 -instances_per_device 1 -hp</cmdline>
<file_ref>
<file_name>MB_6.10_win_SSE3_ATI_HD5_r177.exe</file_name>
<main_program/>
</file_ref>
<file_ref>
<file_name>MultiBeam_Kernels.cl</file_name>
<copy_file/>
</file_ref>
<coproc>
<type>ATI</type>
</coproc>
</app_version>
Although as the app is designed to run on a ATI card then this explains why it was taking both a CPU and GPU slot.

I would have expected that once Boinc parsed the app_info that an error message would have been displayed in Boincmgr's event viewer saying something similar to "You've sepcified a GPU app but have not specified a count value"?
Although to be fair I didn't have the unparsed_xml flag set in the cc_config.

[Ghost0210]

Have just removed the count tag from my Seti app_info given Boinc a restart with the unparsed_xml flag set.
The only error I'm getting in the event viewer is

Code: [Select]

23/03/2011 23:00:22 | SETI@home | Found app_info.xml; using anonymous platform
23/03/2011 23:00:22 | SETI@home | Unparsed line in app_info.xml:
23/03/2011 23:00:22 | SETI@home | Unparsed line in app_info.xml:
23/03/2011 23:00:22 | SETI@home | Unparsed line in app_info.xml:
23/03/2011 23:00:22 | SETI@home Beta Test | Found app_info.xml; using anonymous platform
23/03/2011 23:00:22 | SETI@home Beta Test | Unparsed line in app_info.xml:
23/03/2011 23:00:22 | SETI@home Beta Test | Unparsed line in app_info.xml:
23/03/2011 23:00:22 | SETI@home Beta Test | Unparsed line in app_info.xml:
which I get with or without the <count> tag in place (not sure which lines it has a problem with either as it doesn't specify)
so even without the count tag Boinc doesn't seem to care that you have a malformed app_info

[Richard Haselgrove]

Usually the 'Unparsed line' just refers to a blank line inserted for (human) readability - it's harmless. Did you have exactly three blank lines in the full app_info?

[Ghost0210]

Ok that explains it - I have a blank line between each app in both the app_info's