This one still seems to have passed many by leaving them unaware as the world turns .....
By far the easiest way now to configure machines for BOINC is to use app_config. It will meet the needs of 99% of uses, and only really falls over when trying older software versions of Project Files or carrying out testing of new software.
For 99%+ of Users its a godsend. Once set you just leave it there, and from that moment on it picks up all version changes blah blah from the Project who maintain the server-side information it uses.
Say goodbye to nightmares over cc_config and app_info configurations.
Run don't walk to use it - see (scroll to the bottom of the page):
http://boinc.berkeley.edu/wiki/Client_configuration
BOINC app_config - Use It :)
-
UBT - Timbo
- UBT Forum Admin
- Posts: 9680
- Joined: Mon Mar 13, 2006 12:00 am
- Location: NW Midlands
- Contact:
That's useful.
But seeing the LOOOONG list of criteria that one MIGHT need/want to set, how's about someone comes up with a quick file creation "service" for those who specify particular functions that they want to use....but who haven't sussed out HOW to do it.... !!
Anyone want to volunteer ??
regards
Tim
But seeing the LOOOONG list of criteria that one MIGHT need/want to set, how's about someone comes up with a quick file creation "service" for those who specify particular functions that they want to use....but who haven't sussed out HOW to do it.... !!
Anyone want to volunteer ??
regards
Tim
It really is dead simple ..... I'll put my thinking cap on and come up with a few lines to explain it, and how to use it.
Its so simple, many will be sceptical and will look for "hidden complexity" that in fact isn't there rofl
In the real world there are zero drawbacks to using an app_config.xml
Meanwhile if anyone is stuck, post here, I'll do it for them.
Most will find once they see the result that they will be saying "oh DoH" to themselves
Here is a discussion at BOINC level on this, its three pages, but worth reading. At the start there is a little confusion, but at the halfway stage in the thread, the tides turns, and its being put together like a Pro
http://boinc.berkeley.edu/dev/forum_thr ... stid=47760
Want to cut to the chase? See: Message 47760 in the above link:
Its so simple, many will be sceptical and will look for "hidden complexity" that in fact isn't there rofl
In the real world there are zero drawbacks to using an app_config.xml
Meanwhile if anyone is stuck, post here, I'll do it for them.
Most will find once they see the result that they will be saying "oh DoH" to themselves
Here is a discussion at BOINC level on this, its three pages, but worth reading. At the start there is a little confusion, but at the halfway stage in the thread, the tides turns, and its being put together like a Pro
http://boinc.berkeley.edu/dev/forum_thr ... stid=47760
Want to cut to the chase? See: Message 47760 in the above link:
The verbiage promised above to outline the realities of the "new" app_config.xml.
First off, some basic terminology for those not into it (a little obvious, but the difference does cause confusion in some minds.
Server Side: Activities conceived, controlled and monitored by a Server. The User has little or no control over implementation, and only gets access to the parts the Server wants them to. 99 times out of 100 its information supply to end user, no end user direct control.
End User: The PC run by the end User that takes information from Server-side as required (and allowed) to run applications.
Pre app_config
Prior to the BOINC change, all configuration (or 99% if you want to be picky), was carried out by the end user, the server had no knowledge of the different options et al and needed to be told what to do. That meant that the end user app_info.xml could get very long and intensly complex.
Many times - frankly - it was unnecessarily complex, as too many End Users specified many default values in the app_info that were not needed. Nontheless as we all know, app_info's can be complex beasts, and a nightmare. Under this system, the end user (every end user) had to tell the Server what they wanted; the server, was, (as such) "dumb" and had to be told what was needed, usually via the app_info and/or cc_config files.
Add to that, were several million End Users constantly sending app_info's over the Web/Networks - an horrendous waste of Bandwidth and time.
Post app_config
Under the Server-Side system (app_config), the servers now have access to and the ability to manipulate, all the required end user configuration information. The latter is pretty much unchanged for 99.9% of users, despite the complex looking app_info's some went into. All thats needed now, is to tell the server:
- The application to run
- The total number of WUs to run
- The breakdown of CPU allocation, and the total resource used by individual GPUs
The default Format:
http://boinc.berkeley.edu/wiki/Client_configuration (scroll to bottom of page)
The server already knows your hardware configuration, and knows better than you do what the optimum settings are to run an application (they get laid out by the application developer). All it now needs are the three items above. - job done.
Typical app_config:
<app_config>
<app>
<name>milkyway</name>
<max_concurrent>4</max_concurrent>
<gpu_versions>
<gpu_usage>0.5</gpu_usage>
<cpu_usage>0.15</cpu_usage>
</gpu_versions>
</app>
</app_config>
The above in plain english means:
Dear Server, give me four Milkyway applications, run them two to each of two GPUs (total four running), and on each GPU allocate 0.15 of a CPU for each GPU application - I don't want to run any CPU applications
Another Example for a machine with 4 GPU cards, and keeping one back for non-BOINC use:
In cc_config include this statement:
<ignore_ati_dev>0</ignore_ati_dev>
The app_config:
<app_config>
<app>
<name>milkyway</name>
<max_concurrent>9</max_concurrent>
<gpu_versions>
<gpu_usage>0.33</gpu_usage>
<cpu_usage>0.15</cpu_usage>
</gpu_versions>
</app>
</app_config>
The above in plain english means:
Dear Server,
1. Ignore Device zero for BOINC applicationsI want to do work on it or play Games
2. Give me nine Milkyway applications, run them three to each of the remaining three GPUs (total nine running), and on each GPU allocate 0.15 of a CPU for each GPU application - I don't want to run any CPU applications
This will allow the User to run non-BOINC stuff on GPU 0, and put all BOINC stuff on the rest [GPUs 1-3 inclusive) - effectively setting BOINC up as a background activity and using one GPU to get on with non BOINC stuff. Always set GPU 0 as the "non-BOINC" GPU.
Final Example - BOINC Distrrtgen GPU & CPU on a four GPU PC, running six GPU applications and 8 CPU applications, leaving one GPU & one CPU free for non BOINC useage:
In cc_config include this statement:
<ignore_ati_dev>0</ignore_ati_dev>
The app_config :
<app_config>
<app>
<name>distrrtgen</name>
<max_concurrent>14</max_concurrent>
<gpu_versions>
<gpu_usage>0.5</gpu_usage>
<cpu_usage>1</cpu_usage>
</gpu_versions>
</app>
</app_config>
Dear Server, Leave one GPU core, and 1 CPU core free for non-BOINC useage. Give me 14 distrrtgen WUs in total. Two apps to run on each of three GPUs, and another eight for the Distrrtgen CPU application to run one on each of eight CPU cores, leaving 1 GPU and 1 CPU core free (from the 4 GPU cores and 12 CPU cores on the machine), for non-BOINC use
That should cover most needs - shout with exceptions etc that you need help with
First off, some basic terminology for those not into it (a little obvious, but the difference does cause confusion in some minds.
Server Side: Activities conceived, controlled and monitored by a Server. The User has little or no control over implementation, and only gets access to the parts the Server wants them to. 99 times out of 100 its information supply to end user, no end user direct control.
End User: The PC run by the end User that takes information from Server-side as required (and allowed) to run applications.
Pre app_config
Prior to the BOINC change, all configuration (or 99% if you want to be picky), was carried out by the end user, the server had no knowledge of the different options et al and needed to be told what to do. That meant that the end user app_info.xml could get very long and intensly complex.
Many times - frankly - it was unnecessarily complex, as too many End Users specified many default values in the app_info that were not needed. Nontheless as we all know, app_info's can be complex beasts, and a nightmare. Under this system, the end user (every end user) had to tell the Server what they wanted; the server, was, (as such) "dumb" and had to be told what was needed, usually via the app_info and/or cc_config files.
Add to that, were several million End Users constantly sending app_info's over the Web/Networks - an horrendous waste of Bandwidth and time.
Post app_config
Under the Server-Side system (app_config), the servers now have access to and the ability to manipulate, all the required end user configuration information. The latter is pretty much unchanged for 99.9% of users, despite the complex looking app_info's some went into. All thats needed now, is to tell the server:
- The application to run
- The total number of WUs to run
- The breakdown of CPU allocation, and the total resource used by individual GPUs
The default Format:
http://boinc.berkeley.edu/wiki/Client_configuration (scroll to bottom of page)
The server already knows your hardware configuration, and knows better than you do what the optimum settings are to run an application (they get laid out by the application developer). All it now needs are the three items above. - job done.
Typical app_config:
<app_config>
<app>
<name>milkyway</name>
<max_concurrent>4</max_concurrent>
<gpu_versions>
<gpu_usage>0.5</gpu_usage>
<cpu_usage>0.15</cpu_usage>
</gpu_versions>
</app>
</app_config>
The above in plain english means:
Dear Server, give me four Milkyway applications, run them two to each of two GPUs (total four running), and on each GPU allocate 0.15 of a CPU for each GPU application - I don't want to run any CPU applications
Another Example for a machine with 4 GPU cards, and keeping one back for non-BOINC use:
In cc_config include this statement:
<ignore_ati_dev>0</ignore_ati_dev>
The app_config:
<app_config>
<app>
<name>milkyway</name>
<max_concurrent>9</max_concurrent>
<gpu_versions>
<gpu_usage>0.33</gpu_usage>
<cpu_usage>0.15</cpu_usage>
</gpu_versions>
</app>
</app_config>
The above in plain english means:
Dear Server,
1. Ignore Device zero for BOINC applicationsI want to do work on it or play Games
2. Give me nine Milkyway applications, run them three to each of the remaining three GPUs (total nine running), and on each GPU allocate 0.15 of a CPU for each GPU application - I don't want to run any CPU applications
This will allow the User to run non-BOINC stuff on GPU 0, and put all BOINC stuff on the rest [GPUs 1-3 inclusive) - effectively setting BOINC up as a background activity and using one GPU to get on with non BOINC stuff. Always set GPU 0 as the "non-BOINC" GPU.
Final Example - BOINC Distrrtgen GPU & CPU on a four GPU PC, running six GPU applications and 8 CPU applications, leaving one GPU & one CPU free for non BOINC useage:
In cc_config include this statement:
<ignore_ati_dev>0</ignore_ati_dev>
The app_config :
<app_config>
<app>
<name>distrrtgen</name>
<max_concurrent>14</max_concurrent>
<gpu_versions>
<gpu_usage>0.5</gpu_usage>
<cpu_usage>1</cpu_usage>
</gpu_versions>
</app>
</app_config>
Dear Server, Leave one GPU core, and 1 CPU core free for non-BOINC useage. Give me 14 distrrtgen WUs in total. Two apps to run on each of three GPUs, and another eight for the Distrrtgen CPU application to run one on each of eight CPU cores, leaving 1 GPU and 1 CPU core free (from the 4 GPU cores and 12 CPU cores on the machine), for non-BOINC use
That should cover most needs - shout with exceptions etc that you need help with