- Nov 14, 2000
- 4,823
- 6
- 81
i was asked by an AT forum member and fellow cruncher for some assistance setting up Milkyway@Home to run on an HD 6950 GPU. i thought it might be best to do this by creating an informative thread that provides a foundation/template for running Milkyway@Home optimized applications in general. please note that is not an in-depth explanation of BOINC's "anonymous platform" mechanism. in this thread i will address the app_info.xml, which is the file that enables BOINC anonymous platform mechanism. for a full explanation, please resort to BOINC's own documentation.
as many MW@H participants probably already know, you have a decent amount of control over your host via your MW@H web preferences. for instance, you have quite extensive control over the version of the application you want to run on your host (or more appropriately force the project server to feed your host specific application versions and their associated work/tasks) simply by choosing to run either one or both types of MW@H work (Separation tasks and N-body tasks). likewise, enabling or disabling CPU and/or GPU computing will also force the project server to only send work for specific applications. unfortunately we cannot further manipulate certain characteristics and parameters of the applications via our web preferences once we've chosen the version(s) we want to run. in order to do that, we must go a step further and implement what is known as an app_info.xml file. this file specifies the application version(s) you want to run, as well as contains a number of changeable parameters that affect how the application runs. it must be deployed in the project data directory (in my case, that would be G:\ProgramData\BOINC\projects\milkyway.cs.rpi.edu_milkyway, where the applications themselves and their associated files would be found). while the .XML extension traditionally refers to an Extensible Markup Language file, i believe BOINC and the project server simply reads it like a text file and interprets it as a set of instructions from the host machine. lets take a look at the MW@H app_info.xml file on my Win7/AMD 1090T/HD 6950 platform:
i've bolded the lines of text that are significant in this thread.
starting with the <name> line, you can see my app_info.xml file only specifies a single version of the MW@H Separation application. specifically, it is the version meant for a Windows platform running an AMD/ATI GPU (milkyway_separation_1.02_windows_x86_64__opencl_amd_ati.exe). my app_info.xml specifies no other versions of the Separation application or any kind of the N-body application, and so the AMD/ATI GPU app is the only app that will run on my host unless i edit my app_info.xml file to include yet another app.
the <avg_ncpus> and <max_ncpus> lines can be manipulated to try and improve CPU and/or GPU utilization...but i hardly ever use them b/c i hardly run into utilization problems w/ MW@H, and so i leave them at their default values.
the <count> is an important parameter if you're bent on extracting the most production out of your GPU. it is the GPU utilization factor, and it controls the number of MW@H tasks the application will run simultaneously. by default, its value is one, which corresponds to running a single MW@H task at a time. you can see mine is set to 0.5, which corresponds to 2 MW@H tasks running in parallel. a GPU utilization factor (or <count> value) of 0.33 would correspond to running 3 simultaneous MW@H tasks...though running any more than 2 MW@H Separation tasks simultaneously is a waste of time, as i'll explain shortly...first, i'll start by saying that it is a common misconception that running 2 MW@H Separation tasks simultaneously isn't anymore efficient than running 1 at a time b/c if you run a pair of MW@H tasks, they will appear to take approx. twice the amount of time it takes the same GPU to crunch 1 task. however, it is worth it to note that there is a 3 to 10-second window (depending on the host's CPU and GPU) that starts just after a task reaches 100% during which the entire workload is transferred to the CPU, and GPU utilization drops to zero. obviously running a single MW@H Separation task at a time would result in a few seconds of GPU idling every minute or so on a fairly powerful GPU. likewise, if i run 2 tasks simultaneously and start running them at the same time, for a while they'll stay in sync and hit their 0% GPU utilization points more or less at the same time. but if i offset them by starting only one task at first, and then starting a 2nd task when the first task reaches ~50% progress, i'll see that when the first task reaches 100% and all work associated with it transfers to the CPU, the 2nd task (which is now probably near the 50% mark) will keep the GPU loaded. now i know ~4 seconds of GPU downtime doesn't sound like much, but when it happens every 60-120 seconds, it adds up. in the worst case scenario (i.e. if i were running only 1 MW@H task at a time), this would happen on my host 1394 times a day. multiply that by 4 seconds, and that's 5575 seconds, or 1:33:00. at an average run time of 60s/task, that's 93 tasks. valued at 160 points each, that equates to a loss of 14,880 PPD...not insignificant. b/c we know that 2 simultaneous MW@H Separation tasks take approx. twice the amount of time a single task takes, and b/c we also know that running 2 simultaneous MW@H tasks is enough to eliminate the several seconds of GPU downtime we get at the end of a MW@H Separation task, it is therefore pointless to try and run 3 or more simultaneous MW@H Separation tasks.
the <cmdline> section is a place for additional parameters to be added to the application. i don't really know of any that might be used for MW@H, and i've never needed them, so i've always left this section of the app_info.xml blank for MW@H. now i do run optimized GPU apps for SETI@Home, and my app_info.xml contains -unroll, -ffa, -ffa block, and some other parameters in the <cmdline> section of the app_info.xml...they help w/ GPU utilization and GUI lag, but they are specific to the SETI@Home project...though i'm sure there are also <cmdline> parameters that are common to all BOINC projects. at any rate, for MW@H, i wouldn't be too concerned about this section of the app_info.xml.
How To Make An app_info.xml file for Milkyway@Home:
open Microsoft Worpad or the equivalent word processor on your platform (i'm obviously using Windows). DO NOT use MS Word, Corel Word Perfect, or any of the fancier word processors, as they can occasionally add invisible (and unwanted) characters to your text later during the save process, and that can wreak havoc lol. next, add the text you see in the code box below, and edit the <file_info> section to work w/ your platform/OS. make sure the GPU utilization factor is what you want it to be (for Milkyway@Home, either 1 or 0.5). finally, save the file as "app_info.txt" and rename the "txt" file extension to "xml." now you have an app_info.xml file that is ready to be placed in your MW@H data directory.
well that more or less sums up the app_info.xml for the Milkyway@Home project. keep in mind that BOINC's anonymous platform mechanism and the app_info.xml file can be used for a multitude or projects, and is not limited to MW@H. i hope this ends up being helpful for many of you, and if you have any questions, i'll do my best to answer them.
as many MW@H participants probably already know, you have a decent amount of control over your host via your MW@H web preferences. for instance, you have quite extensive control over the version of the application you want to run on your host (or more appropriately force the project server to feed your host specific application versions and their associated work/tasks) simply by choosing to run either one or both types of MW@H work (Separation tasks and N-body tasks). likewise, enabling or disabling CPU and/or GPU computing will also force the project server to only send work for specific applications. unfortunately we cannot further manipulate certain characteristics and parameters of the applications via our web preferences once we've chosen the version(s) we want to run. in order to do that, we must go a step further and implement what is known as an app_info.xml file. this file specifies the application version(s) you want to run, as well as contains a number of changeable parameters that affect how the application runs. it must be deployed in the project data directory (in my case, that would be G:\ProgramData\BOINC\projects\milkyway.cs.rpi.edu_milkyway, where the applications themselves and their associated files would be found). while the .XML extension traditionally refers to an Extensible Markup Language file, i believe BOINC and the project server simply reads it like a text file and interprets it as a set of instructions from the host machine. lets take a look at the MW@H app_info.xml file on my Win7/AMD 1090T/HD 6950 platform:
Code:
<app_info>
<app>
<name>milkyway</name>
</app>
<file_info>
[B] <name>milkyway_separation_1.02_windows_x86_64__opencl_amd_ati.exe</name>[/B]
<executable/>
</file_info>
<app_version>
<app_name>milkyway</app_name>
<version_num>102</version_num>
<flops>1.0e11</flops>
[B]<avg_ncpus>0.05</avg_ncpus>
<max_ncpus>1</max_ncpus>[/B]
<plan_class>ati14ati</plan_class>
<coproc>
<type>ATI</type>
[B]<count>0.5</count>[/B]
</coproc>
[B]<cmdline></cmdline>[/B]
<file_ref>
[B] <file_name>milkyway_separation_1.02_windows_x86_64__opencl_amd_ati.exe</file_name>[/B]
<main_program/>
</file_ref>
</app_version>
</app_info>starting with the <name> line, you can see my app_info.xml file only specifies a single version of the MW@H Separation application. specifically, it is the version meant for a Windows platform running an AMD/ATI GPU (milkyway_separation_1.02_windows_x86_64__opencl_amd_ati.exe). my app_info.xml specifies no other versions of the Separation application or any kind of the N-body application, and so the AMD/ATI GPU app is the only app that will run on my host unless i edit my app_info.xml file to include yet another app.
the <avg_ncpus> and <max_ncpus> lines can be manipulated to try and improve CPU and/or GPU utilization...but i hardly ever use them b/c i hardly run into utilization problems w/ MW@H, and so i leave them at their default values.
the <count> is an important parameter if you're bent on extracting the most production out of your GPU. it is the GPU utilization factor, and it controls the number of MW@H tasks the application will run simultaneously. by default, its value is one, which corresponds to running a single MW@H task at a time. you can see mine is set to 0.5, which corresponds to 2 MW@H tasks running in parallel. a GPU utilization factor (or <count> value) of 0.33 would correspond to running 3 simultaneous MW@H tasks...though running any more than 2 MW@H Separation tasks simultaneously is a waste of time, as i'll explain shortly...first, i'll start by saying that it is a common misconception that running 2 MW@H Separation tasks simultaneously isn't anymore efficient than running 1 at a time b/c if you run a pair of MW@H tasks, they will appear to take approx. twice the amount of time it takes the same GPU to crunch 1 task. however, it is worth it to note that there is a 3 to 10-second window (depending on the host's CPU and GPU) that starts just after a task reaches 100% during which the entire workload is transferred to the CPU, and GPU utilization drops to zero. obviously running a single MW@H Separation task at a time would result in a few seconds of GPU idling every minute or so on a fairly powerful GPU. likewise, if i run 2 tasks simultaneously and start running them at the same time, for a while they'll stay in sync and hit their 0% GPU utilization points more or less at the same time. but if i offset them by starting only one task at first, and then starting a 2nd task when the first task reaches ~50% progress, i'll see that when the first task reaches 100% and all work associated with it transfers to the CPU, the 2nd task (which is now probably near the 50% mark) will keep the GPU loaded. now i know ~4 seconds of GPU downtime doesn't sound like much, but when it happens every 60-120 seconds, it adds up. in the worst case scenario (i.e. if i were running only 1 MW@H task at a time), this would happen on my host 1394 times a day. multiply that by 4 seconds, and that's 5575 seconds, or 1:33:00. at an average run time of 60s/task, that's 93 tasks. valued at 160 points each, that equates to a loss of 14,880 PPD...not insignificant. b/c we know that 2 simultaneous MW@H Separation tasks take approx. twice the amount of time a single task takes, and b/c we also know that running 2 simultaneous MW@H tasks is enough to eliminate the several seconds of GPU downtime we get at the end of a MW@H Separation task, it is therefore pointless to try and run 3 or more simultaneous MW@H Separation tasks.
the <cmdline> section is a place for additional parameters to be added to the application. i don't really know of any that might be used for MW@H, and i've never needed them, so i've always left this section of the app_info.xml blank for MW@H. now i do run optimized GPU apps for SETI@Home, and my app_info.xml contains -unroll, -ffa, -ffa block, and some other parameters in the <cmdline> section of the app_info.xml...they help w/ GPU utilization and GUI lag, but they are specific to the SETI@Home project...though i'm sure there are also <cmdline> parameters that are common to all BOINC projects. at any rate, for MW@H, i wouldn't be too concerned about this section of the app_info.xml.
How To Make An app_info.xml file for Milkyway@Home:
open Microsoft Worpad or the equivalent word processor on your platform (i'm obviously using Windows). DO NOT use MS Word, Corel Word Perfect, or any of the fancier word processors, as they can occasionally add invisible (and unwanted) characters to your text later during the save process, and that can wreak havoc lol. next, add the text you see in the code box below, and edit the <file_info> section to work w/ your platform/OS. make sure the GPU utilization factor is what you want it to be (for Milkyway@Home, either 1 or 0.5). finally, save the file as "app_info.txt" and rename the "txt" file extension to "xml." now you have an app_info.xml file that is ready to be placed in your MW@H data directory.
well that more or less sums up the app_info.xml for the Milkyway@Home project. keep in mind that BOINC's anonymous platform mechanism and the app_info.xml file can be used for a multitude or projects, and is not limited to MW@H. i hope this ends up being helpful for many of you, and if you have any questions, i'll do my best to answer them.
Last edited:
I might also completely remove BOINC and the old drivers again, then reinstall, to ensure clean install, though I thought I had done completely.. but once again to make sure.
Facebook
Twitter