Forum > Discussion Forum
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:
--- Quote from: Ghost on 20 Mar 2011, 06:32:57 pm ---Other than my use for tag is there a purpose that I'm overlooking for the plan_class tag?
--- End quote ---
Nope, in essence it's just a name for display, and I've done that myself in the past, so change away ;D
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 ;D)
Ghost
Richard Haselgrove:
--- Quote from: Jason G on 20 Mar 2011, 06:48:44 pm ---.... I've passed installer work into other capable hands that may decide to change that sort of thing.
--- End quote ---
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
Navigation
[0] Message Index
[#] Next page
Go to full version