This just in - new in BOINC v7.0.40/.41
May I draw testers' attention to http://boinc.berkeley.edu/wiki/Client_configuration#Application_configuration
Very new, very experimental, not very well documented - but hey, you testers are all intelligent people, you'll be able to work it out for yourselves, I'm sure.
What we've found is that you can use the
tag on its own (without using a <max_concurrent> tag at all), and it functions - empirically - as a <count> specification for GPU apps.
That wasn't the intended purpose, of course, and like all new and experimental features it'll be subject to change - but in this form it's ideal for testing here. There are some people who go though all the trouble of writing their own app_info.xml file, just so that they can run multiple instances on a GPU. In the process, they lose the automatic downloading of new application versions as they are released for testing - and may find themselves still running an old version which has been withdrawn because bugs have been found.
This new facility gives you the best of both worlds - finer control over BOINC's application scheduling, while keeping stock application downloads. And it'll save Eric the hassle of copying Einstein's server-managed <count> preference control - the two work together, I've tested that too.
<app>
<name>uppercase</name>
<max_concurrent>1</max_concurrent>
<gpu_versions>
<gpu_usage>.5</gpu_usage>
<cpu_usage>.4</cpu_usage>
</gpu_versions>
</app>
</app_config>
Cause you already passed some way on this road could you share example of your own app_config.
For example, what is <name>uppercase</name>: setiathome_v7 ? (for MultiBeam V7 tasks on beta)
And cause "uppercase" should it be SETIATHOME_V7 ?
Cause you already passed some way on this road could you share example of your own app_config.
For example, what is <name>uppercase</name>: setiathome_v7 ? (for MultiBeam V7 tasks on beta)
And cause "uppercase" should it be SETIATHOME_V7 ?
No, 'uppercase' is just an example of a name - the uppercase application is BOINC's equivalent of the "Hello World" program for new BOINC server operators.
Just use the same name as you would put in app_info.xml for the same app/project - you can read it from client_state.xml if you aren't running anonymous platform.
http://clip2net.com/s/2Gh06
Working just as should. It's ideal for making GPU busy with stock Brook+ APv6
app_config.xml was:
<app>
<name>astropulse_v6</name>
<max_concurrent>4</max_concurrent>
<gpu_versions>
<gpu_usage>0.1</gpu_usage>
<cpu_usage>0.1</cpu_usage>
</gpu_versions>
</app>
</app_config>
Any luck in getting an option for cal_ati marked/unmarked in seti/setiBeta prefs?
The app is still in mix with ordinary asteopulse tasks.
And you have your example using 0.1cpu
Doesn't the app use 1.0cpu each?
Any luck in getting an option for cal_ati marked/unmarked in seti/setiBeta prefs?
It's qustion to Eric.
Actually, we should never send hybrid AP to hosts that OpenCL capable. Only to CAL-only hosts.
The app is still in mix with ordinary asteopulse tasks.
And you have your example using 0.1cpu
Doesn't the app use 1.0cpu each?
Real GPU and CPU usage % will depend on relative speeds of particular CPU and GPU.
For example, for C-60 APU mean GPU usage ~10% (averaged on 1/5 of low-blanked task).
For HD6950 host I use anothr app_config.xml now:
This one + 75% CPU usage allows to run with 1 OpenCL app and free CPU core to make OpenCL app fast.
But for hybrid AP this config is artifical. As I already said "in wild" hybrid AP should never run togethr with OpenCL app. So, to allow better GPU load CPU should be overcommitted. Hence low cpu_usage fraction and low GPU usage fraction. Just to allow few tasks run together.
Any luck in getting an option for cal_ati marked/unmarked in seti/setiBeta prefs?
It's qustion to Eric.
Actually, we should never send hybrid AP to hosts that OpenCL capable. Only to CAL-only hosts.
The app is still in mix with ordinary asteopulse tasks.
And you have your example using 0.1cpu
Doesn't the app use 1.0cpu each?
Real GPU and CPU usage % will depend on relative speeds of particular CPU and GPU.
For example, for C-60 APU mean GPU usage ~10% (averaged on 1/5 of low-blanked task).
For HD6950 host I use anothr app_config.xml now:
This one + 75% CPU usage allows to run with 1 OpenCL app and free CPU core to make OpenCL app fast.
But for hybrid AP this config is artifical. As I already said "in wild" hybrid AP should never run togethr with OpenCL app. So, to allow better GPU load CPU should be overcommitted. Hence low cpu_usage fraction and low GPU usage fraction. Just to allow few tasks run together.
Ok
It feels a bit a waste of GPU usage for my 5850 to run more cal_ati tasks.
It works fine with driver 12.3
As you say only non Open CL and cal supported cards should get the cal_ati tasks.
i'll run 8 more cal_ati tasks.
I'll run them(2-3 at a time)(using app_config.xml) together with 1-2 SETI ap and 1 Moowrap task on(3gpu's(multi=1))(and exclude gpu 0,2) on the Moowrap task to use all 3 gpu's for 1 moowrap task.
This multi gpu rig is kind of fun. :)
http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=62304
1'st is almost complete.
How many more do you need?
After more close study of the gpu usage of my current configuration.
I see the Moowrap task isn't allowed much of Gpu time from the Gpu's running cal_ati tasks.
When running SETI Beta tasks moowrap gets more gpu time from the seti ap gpu's.
I guess that is the way of the Brook programming.
It's no big deal, just an observation, the cal_ati functions very well even with other tasks running on the gpu's.
Removing -hp from the cal_ati tasks increased the Moowrap gpu usage...
Here are some fresh tasks runned with app_config.xml
2 tasks on each gpu alternating with Seti Main ap tasks on 2-3 Gpu's
http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=62304
No problems detected.