On my i7/930 machine which is a pure v7 machine doing non AP work. There is a file called the app_config.xml that I believe was created by the Lunatics v0.41 installer that is not on the i7/950 machine, which uses the app_info.xml. The machine is question has a GTX460SE GPU @ 1 Gb and for some reason the scheduler has filled its queue with plan _class Cuda32 work as opposed to either Cuda42 or Cuda Fermi. So two questions exists 1) Does the app_config have precedence over the app_info file if both files are on the same machine, and is it safe to remove one or the other? 2) How can I direct the scheduling server to send only plan_class Cuda42 or Fermi?

---

I don't buy computers, I build them!!

I got confused.

If we are talking about the machine that you DID run v41 on, then you left the default CUDA checked on installation and that will give you nothing but CUDA 32.

Shut-down BOINC and re-run the installer and make sure you select the CUDA 42 check box.

If we are talking about the machine you DID NOT install the Lunatics v41 on, then as you probably already know, the servers are going to send whatever they are going to send until they "figure it out" and start sending you the right CUDA version WUs.

AS far as app_config and app_info go, I'd leave them both alone until you get the other situation dealt-with.

It's "easier" to deal with some things in app_config than app_info (in my opinion). I have machines with both and I use entries in each (i.e., it's not hurting anything).

<edit: I don't know which is read first and which last, but I would think it would be the *last* entry for a thing that gets used.>

I got confused.

If we are talking about the machine that you DID run v41 on, then you left the default CUDA checked on installation and that will give you nothing but CUDA 32.

Shut-down BOINC and re-run the installer and make sure you select the CUDA 42 check box.

If we are talking about the machine you DID NOT install the Lunatics v41 on, then as you probably already know, the servers are going to send whatever they are going to send until they "figure it out" and start sending you the right CUDA version WUs.

AS far as app_config and app_info go, I'd leave them both alone until you get the other situation dealt-with.

It's "easier" to deal with some things in app_config than app_info (in my opinion). I have machines with both and I use entries in each (i.e., it's not hurting anything).

<edit: I don't know which is read first and which last, but I would think it would be the *last* entry for a thing that gets used.>

Lunatics is/was currently running on both machines when the initial post was made. I ended up removing both the app_info & app_config .xml files and re-installing Lunatics for the 3rd time using the same settings that I used on the initial install. Don't know what happened on the first two installs, but the Cuda32 tasks are down to 18 and 80 Cuda42 tasks loaded overnight.

---

I don't buy computers, I build them!!

On my i7/930 machine which is a pure v7 machine doing non AP work. There is a file called the app_config.xml that I believe was created by the Lunatics v0.41 installer that is not on the i7/950 machine, which uses the app_info.xml. The machine is question has a GTX460SE GPU @ 1 Gb and for some reason the scheduler has filled its queue with plan _class Cuda32 work as opposed to either Cuda42 or Cuda Fermi. So two questions exists 1) Does the app_config have precedence over the app_info file if both files are on the same machine, and is it safe to remove one or the other? 2) How can I direct the scheduling server to send only plan_class Cuda42 or Fermi?

The Lunatics installer only creates app_info.xml files not app_config.xml files.

The app_config file is read later and therefore takes precedence.

The app_config files ONLY allows you to run several WUs at once (same as changing <count> in app_info.xml), or to limit the total amount of concurrent tasks.

If you have an Lunatics installer generated app_info.xml you should NOT remove it unless you wish to crunch stock. You MAY use the app_config.xml file to change <count> instead of editing app_info.xml. As an added bonus app_config.xml can be read on the fly (read config) whereas changes to app_info.xml require a BOINC restart.

ad b) You can't. You can use the Lunatics installer and pick the app you want. Else you have to rely on the server to eventually find the app/plan_class with the best speed.

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

The app_config file is read later and therefore takes precedence.

Therein lies one of the problems that I had. Regardless of what changes I made to the app_info.xml, they were being over-ridden by the app_config.xml.

---

I don't buy computers, I build them!!

The app_config file is read later and therefore takes precedence.

Therein lies one of the problems that I had. Regardless of what changes I made to the app_info.xml, they were being over-ridden by the app_config.xml.

Just curious, what was in the app_config that was changing your changes in the app_info?

The app_config file is read later and therefore takes precedence.

Therein lies one of the problems that I had. Regardless of what changes I made to the app_info.xml, they were being over-ridden by the app_config.xml.

Just curious, what was in the app_config that was changing your changes in the app_info?

What ever the default for that file was. Regardless of how I configured the count for the GPU tasks, it never took place. Once I deleted both files and re-installed Lunatics and set the counts for Cuda42, Fermi, & Cuda32, everything started working the way it was supposed to. The count for Cuda32 tasks was included in the app_info.xml modifications because I didn't want to lose the work. Still playing with the counts.

---

I don't buy computers, I build them!!

The app_config file is read later and therefore takes precedence.

Therein lies one of the problems that I had. Regardless of what changes I made to the app_info.xml, they were being over-ridden by the app_config.xml.

Just curious, what was in the app_config that was changing your changes in the app_info?

What ever the default for that file was. Regardless of how I configured the count for the GPU tasks, it never took place. Once I deleted both files and re-installed Lunatics and set the counts for Cuda42, Fermi, & Cuda32, everything started working the way it was supposed to. The count for Cuda32 tasks was included in the app_info.xml modifications because I didn't want to lose the work. Still playing with the counts.

There isn't an app_config.xml be default. It would only exist if you created it. Personally I think it makes adjusting the number of task to run easier than scanning though the app_info.xml to find the various values to adjust, but that is just me.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

One thing in favor to use the app_config.xml is if you need to reinstall the lunnatics/boinc for any reason you don´t loose your configuration.

---

The app_config file is read later and therefore takes precedence.

Therein lies one of the problems that I had. Regardless of what changes I made to the app_info.xml, they were being over-ridden by the app_config.xml.

Just curious, what was in the app_config that was changing your changes in the app_info?

What ever the default for that file was. Regardless of how I configured the count for the GPU tasks, it never took place. Once I deleted both files and re-installed Lunatics and set the counts for Cuda42, Fermi, & Cuda32, everything started working the way it was supposed to. The count for Cuda32 tasks was included in the app_info.xml modifications because I didn't want to lose the work. Still playing with the counts.

There isn't an app_config.xml be default. It would only exist if you created it. Personally I think it makes adjusting the number of task to run easier than scanning though the app_info.xml to find the various values to adjust, but that is just me.

I almost never create a new file unless I know what is going on with it. With that in mind it seems that the file was created on 31 May, 2013 with following settings

<app_config>
<app>
<name>setiathome_v7</name>
<gpu_versions>
<gpu_usage>0.5</gpu_usage>
<cpu_usage>.04</cpu_usage>
</gpu_versions>
</app>
</app_config>

So, are you telling me that I can cherry pick what I want out of the app_info.xml and insert it into the app_config.xml, and then rely on the app_config to make any changes to the general configuration? With what I see here is that all GPU work for v7 will have the same overrides regardless of whether it is for AP or MB, please tell me if I'm wrong. I'm not concerned with the i7/930 machine as it doesn't do AP per se, but on the i7/950, which does primarily AP work, when its available, it would be nice to use.

---

I don't buy computers, I build them!!

You need to add to the file the AP portion (and the old V6 if you still have any too) or it will not work when you run AP.

This is my file: (i allow only to run one AP on each of my GPU´s because they need an entire CPU core to feed the GPU and i use multiple GPUs hosts)

<app_config>
<app>
<name>setiathome_v7</name>
<gpu_versions>
<gpu_usage>0.49</gpu_usage>
<cpu_usage>0.06</cpu_usage>
</gpu_versions>
</app>
<app>
<name>setiathome_enhanced</name>
<gpu_versions>
<gpu_usage>0.49</gpu_usage>
<cpu_usage>0.06</cpu_usage>
</gpu_versions>
</app>
<app>
<name>astropulse_v6</name>
<max_concurrent>6</max_concurrent>
<gpu_versions>
<gpu_usage>0.51</gpu_usage>
<cpu_usage>1.00</cpu_usage>
</gpu_versions>
</app>
</app_config>

---

The app_config file is read later and therefore takes precedence.

Therein lies one of the problems that I had. Regardless of what changes I made to the app_info.xml, they were being over-ridden by the app_config.xml.

Just curious, what was in the app_config that was changing your changes in the app_info?

What ever the default for that file was. Regardless of how I configured the count for the GPU tasks, it never took place. Once I deleted both files and re-installed Lunatics and set the counts for Cuda42, Fermi, & Cuda32, everything started working the way it was supposed to. The count for Cuda32 tasks was included in the app_info.xml modifications because I didn't want to lose the work. Still playing with the counts.

There isn't an app_config.xml be default. It would only exist if you created it. Personally I think it makes adjusting the number of task to run easier than scanning though the app_info.xml to find the various values to adjust, but that is just me.

I almost never create a new file unless I know what is going on with it. With that in mind it seems that the file was created on 31 May, 2013 with following settings

<app_config>
<app>
<name>setiathome_v7</name>
<gpu_versions>
<gpu_usage>0.5</gpu_usage>
<cpu_usage>.04</cpu_usage>
</gpu_versions>
</app>
</app_config>

So, are you telling me that I can cherry pick what I want out of the app_info.xml and insert it into the app_config.xml, and then rely on the app_config to make any changes to the general configuration? With what I see here is that all GPU work for v7 will have the same overrides regardless of whether it is for AP or MB, please tell me if I'm wrong. I'm not concerned with the i7/930 machine as it doesn't do AP per se, but on the i7/950, which does primarily AP work, when its available, it would be nice to use.

Hopefully juan's reply got you all sorted out on the app_config.xml. If it didn't there are instructions that give detailed descriptions of what each parameter does.
It occurs to me that the <max_concurrent> tag could be used to reserve CPU's/cores for feeding GPU's. Since it indicates that GPU tasks are started before CPU tasks. Then quad CPU dual GPU system running 2 tasks on each card could be set to <max_concurrent>6</max_concurrent>. Freeing up 2 cores while the GPU's are busy and then running more CPU cores when the GPU's are idle.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

It occurs to me that the <max_concurrent> tag could be used to reserve CPU's/cores for feeding GPU's. Since it indicates that GPU tasks are started before CPU tasks. Then quad CPU dual GPU system running 2 tasks on each card could be set to <max_concurrent>6</max_concurrent>. Freeing up 2 cores while the GPU's are busy and then running more CPU cores when the GPU's are idle.

That´s exactly what <cpu_usage>1.00</cpu_usage> does, reserve an entire core for each AP WU when crunching and leave free to crunch CPU WU when no AP are avaiable. MB uses so few CPU resources to be worry about unless you have a AMD CPU (if that is your case most of the AMD users recomend on the forums to leave an aditional core to feed the GPU)

I use <max_concurrent>6<max_concurrent> because this host have 4 GPU´s so that avoid the SETI run more than 6 AP WU at a time (4 GPU+ 2 CPU). Normaly you don´t need to use it if you have a single GPU host. Unless you have a top GPU (680/770 etc) in most of the cases when you crunch 2 WU at a time you get the best performance (of course you need to test on your particular host to be sure about that)

---

It occurs to me that the <max_concurrent> tag could be used to reserve CPU's/cores for feeding GPU's. Since it indicates that GPU tasks are started before CPU tasks. Then quad CPU dual GPU system running 2 tasks on each card could be set to <max_concurrent>6</max_concurrent>. Freeing up 2 cores while the GPU's are busy and then running more CPU cores when the GPU's are idle.

That´s exactly what <cpu_usage>1.00</cpu_usage> does, reserve an entire core for each AP WU when crunching and leave free to crunch CPU WU when no AP are avaiable. MB uses so few CPU resources to be worry about unless you have a AMD CPU (if that is your case most of the AMD users recomend on the forums to leave an aditional core to feed the GPU)

I use <max_concurrent>6<max_concurrent> because this host have 4 GPU´s so that avoid the SETI run more than 6 AP WU at a time (4 GPU+ 2 CPU). Normaly you don´t need to use it if you have a single GPU host. Unless you have a top GPU (680/770 etc) in most of the cases when you crunch 2 WU at a time you get the best performance (of course you need to test on your particular host to be sure about that)

Yes <cpu_usage> can be used in a similar fashion, but I was thinking about MB instead of AP. Just different ways to do the exact same thing really.
On my 24 core box I use just this:

<app_config>
	<app>
		<name>astropulse_v6</name>
		<max_concurrent>18</max_concurrent>
	</app>
</app_config>

To limit the number of AP that run at once. As 24 AP at a time does make the system sluggish. So when it can get AP work it will run a max of 18 with 6 MB, or any variation depending on how many AP it can snag. I just wish I could limit VLAR like this as well. Since 24 VLAR at once bog the system down too.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[