Author |
Message |
|
Hello: You can use <app_config.xml> two tasks to run on a GPU, if so, what is the name of the project or projects to set app_config GPUGRID correctly in "<name>??????? </ name> " in BOINC 7.0.54 |
|
|
|
Hello: Solved, by trial and error.
Is: "acemdshort" for short tasks and suppose to be the equivalent long. |
|
|
|
Hello: So far works perfectly running two GPU tasks (tasks GTX590x4) plus 1 CPU per task.
We'll see if the performance is worth a whole ...?. |
|
|
|
We'll see if the performance is worth a whole ...?.
Probably not.. it hasn't been up to now. And make sure not to miss the early-return-credit-bonus (24h) due to running 2 WUs/GPU.
MrS
____________
Scanning for our furry friends since Jan 2002 |
|
|
|
Hello: In the first tasks undertaken by configuring TWO tasks per GPU the result is not very encouraging.
The gain in execution time is an average of 5%, that's something but not enough for me.
Obviously only applies to short tasks to keep the bonus.
In other projects like WCG gain is 30% on average, I guess in GPUGRID GPU load is already highly optimized and there is no room. |
|
|
skgivenVolunteer moderator Volunteer tester
Send message
Joined: 23 Apr 09 Posts: 3968 Credit: 1,995,359,260 RAC: 0 Level
Scientific publications
|
Thanks for reporting on your trial Carlesa25; it confirms the status quo.
In the past, I've tested this to exhaustion and at GPUGRID there is little or no gain unless GPU utilization drops below 80%. Even then there's only a moderate increase unless utilization drops to around 60%.
A subsequent concern is the number of different task types run at GPUGRID; typically there are two or three, but sometimes more, so any gain would only apply when you get two similarly low GPU utilizing tasks.
While it's been demonstrated that you can mix apps from different projects and achieve better overall Boinc credits, it's very high maintenance and not something for the novice (not saying you are).
As the project is largely Beta testing, it's really a bad time to be testing app_* and or overclocking.
____________
FAQ's
HOW TO:
- Opt out of Beta Tests
- Ask for Help |
|
|
|
Hello: I still have some testing to confirm results, for which the interested reader this is the configuration file app_config.xml replaced in the project directory GPUGRID.
<app_config>
<app>
<name>acemd2</ name>
<max_concurrent>4</ max_concurrent>
<gpu_versions>
<gpu_usage>.5</ gpu_usage>
<cpu_usage>1</ cpu_usage>
</gpu_versions>
</app>
</app_config>
Note that in order to work with the two types of short tasks become the name "acemd2" instead of "acemdshort" discussed above.
With this configuration we perform two tasks per GPU and CPU by assigning a task, in this case it is a GTX590 performing 4 tasks using two GPUs and 4 CPUs. Greetings. |
|
|
|
I'll chime in with my information.
I have 2 nVidia GPUs (GTX 660 Ti, and GTX 460).
When I watch some of the GPUGrid tasks run, I notice that some of them use a CPU all of the time, some tasks only use a CPU part of the time, and some don't really use much CPU. Also, the GPUGrid processes appear to have been tweaked such that the base priority is "Below Normal", which is above "Low" (which CPU tasks use).
With that in mind, since I have 2 video cards and care very much about my other CPU projects, I have decided to use the following app_config.xml. Essentially, I've set it up with 0.499 for cpu_usage, so that even when both video cards are crunching GPUGrid tasks, my CPUs are still kept busy. The GPUGrid projects still get all the CPU they'd need/want (because their base priority is special), and when I happen to get GPUGrid tasks that don't use much CPU, my CPU tasks pick up the slack (Since 0.499 + 0.499 < 1.000, meaning that a CPU core is NOT reserved for GPUGrid)... and the result is always 100% CPU utilization.
I hope you understand that logic. It works well for me.
<app_config>
<app>
<name>acemdbeta</name>
<max_concurrent>50</max_concurrent>
<gpu_versions>
<gpu_usage>1</gpu_usage>
<cpu_usage>0.499</cpu_usage>
</gpu_versions>
</app>
<app>
<name>acemdlong</name>
<max_concurrent>50</max_concurrent>
<gpu_versions>
<gpu_usage>1</gpu_usage>
<cpu_usage>0.499</cpu_usage>
</gpu_versions>
</app>
<app>
<name>acemd2</name>
<max_concurrent>50</max_concurrent>
<gpu_versions>
<gpu_usage>1</gpu_usage>
<cpu_usage>0.499</cpu_usage>
</gpu_versions>
</app>
<app>
<name>acemdshort</name>
<max_concurrent>50</max_concurrent>
<gpu_versions>
<gpu_usage>1</gpu_usage>
<cpu_usage>0.499</cpu_usage>
</gpu_versions>
</app>
</app_config>
PS: To figure out application names for a given project, you could look at the client_state.xml file. You might also be able to look at the scheduler request xml file for that information. |
|
|
|
Hello: "<max_concurrent>50</max_concurrent>" this means that can perform 50 tasks simultaneously ... but assigns only one GPU, I do not understand this configuration. |
|
|
|
I believe <max_concurrent> means "run up to this many tasks at once, of this application, across your entire computer"
Since I only have 2 GPUs, and I'm only running 1 task per GPU, I could theoretically set it as low as 2 and it wouldn't have any effect.
I just put it to 50 to ensure it never limits me, and to satisfy the spec found at http://boinc.berkeley.edu/trac/wiki/ClientAppConfig. Though I'm told the <max_concurrent> line can be omitted, I'd prefer not to risk it, so I just set it arbitrarily high, to 50.
It's the <gpu_usage> and <cpu_usage> settings that determine how many tasks run at the same time on a given GPU, and how much CPU each task takes.
Make sense?
Come to think of it, in case I add more GPUs in the future, I'll probably go ahead and set <cpu_usage> arbitrarily low, to 0.001, for each of the apps, that way even if I had 3+ GPUs, a CPU core would never be reserved. |
|
|
|
Make sense?
Yes.
Come to think of it, in case I add more GPUs in the future, I'll probably go ahead and set <cpu_usage> arbitrarily low, to 0.001, for each of the apps, that way even if I had 3+ GPUs, a CPU core would never be reserved.
I understand CPU projects are important for you.. but this could starve (some of) your GPUs running GPU-Grid. Feel free to test it, though, and report your findings here!
MrS
____________
Scanning for our furry friends since Jan 2002 |
|
|
|
I have tested it already. While watching Task Manager's Details tab, sorted by CPU descending, I see that the acemd process is never starved for CPU, even though other running CPU tasks are (at times) starved.
This is because the acemd process is running at a higher priority; the "base priority" column shows "Below normal" for the acemd task, which is higher than the "Low" priority that the CPU tasks get. Process Explorer also confirms that the GPUGrid process is running priority 6, whereas the CPU tasks are running priority 4.
So, even though the computer is a bit overloaded (especially when a GPUGrid task actually does use a CPU core most of the time), only CPU projects are getting starved. And my CPU is always at 100% usage. It works wonderfully.
So, now my app_config.xml file is:
<app_config>
<app>
<name>acemdbeta</name>
<max_concurrent>9999</max_concurrent>
<gpu_versions>
<gpu_usage>1</gpu_usage>
<cpu_usage>0.001</cpu_usage>
</gpu_versions>
</app>
<app>
<name>acemdlong</name>
<max_concurrent>9999</max_concurrent>
<gpu_versions>
<gpu_usage>1</gpu_usage>
<cpu_usage>0.001</cpu_usage>
</gpu_versions>
</app>
<app>
<name>acemd2</name>
<max_concurrent>9999</max_concurrent>
<gpu_versions>
<gpu_usage>1</gpu_usage>
<cpu_usage>0.001</cpu_usage>
</gpu_versions>
</app>
<app>
<name>acemdshort</name>
<max_concurrent>9999</max_concurrent>
<gpu_versions>
<gpu_usage>1</gpu_usage>
<cpu_usage>0.001</cpu_usage>
</gpu_versions>
</app>
</app_config>
|
|
|
OperatorSend message
Joined: 15 May 11 Posts: 108 Credit: 297,176,099 RAC: 0 Level
Scientific publications
|
Carlesa25;
I tried using your app_config.xml example to run 2 WU per GPU on 2x GTX 590 for acemdlong WU.
I'm using BOINC 7.0.52.
I still get only 1 WU per GPU running.
I put the app_config.xml in the GPUGrid.net project directory.
Any suggestions?
Thanks,
Operator
____________
|
|
|
|
Assuming you have the app_config.xml file in the right location (mine is within the folder: C:\ProgramData\BOINC\projects\www.gpugrid.net)
You'll have to get BOINC to read the file, either by
Clicking Advanced -> Read config file, or
Restarting BOINC
In the Event Log, you'll know the file was read, when you see the following line:
3/22/2013 5:32:27 PM | GPUGRID | Found app_config.xml
... within the startup block (Mine is pasted below).
Finally, once the app_config.xml is read, BOINC should show tasks using your configured amount of resources. For instance, my GPUGrid tasks say: "Running (0.001 CPUs + 1 NVIDIA GPU)" If BOINC doesn't show the task using the resources you configured, then try restarting BOINC.
Good luck - Hope you get it to work!
3/22/2013 5:32:27 PM | | Starting BOINC client version 7.0.58 for windows_x86_64
3/22/2013 5:32:27 PM | | log flags: file_xfer, sched_ops, task, cpu_sched, unparsed_xml, work_fetch_debug
3/22/2013 5:32:27 PM | | Libraries: libcurl/7.25.0 OpenSSL/1.0.1 zlib/1.2.6
3/22/2013 5:32:27 PM | | Data directory: C:\ProgramData\BOINC
3/22/2013 5:32:27 PM | | Running under account Jacob
3/22/2013 5:32:27 PM | | Processor: 8 GenuineIntel Intel(R) Core(TM) i7 CPU 965 @ 3.20GHz [Family 6 Model 26 Stepping 4]
3/22/2013 5:32:27 PM | | Processor features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss htt tm pni ssse3 cx16 sse4_1 sse4_2 popcnt syscall nx lm vmx tm2 pbe
3/22/2013 5:32:27 PM | | OS: Microsoft Windows 8: Professional with Media Center x64 Edition, (06.02.9200.00)
3/22/2013 5:32:27 PM | | Memory: 5.99 GB physical, 21.99 GB virtual
3/22/2013 5:32:27 PM | | Disk: 277.28 GB total, 185.49 GB free
3/22/2013 5:32:27 PM | | Local time is UTC -4 hours
3/22/2013 5:32:27 PM | | CUDA: NVIDIA GPU 0: GeForce GTX 660 Ti (driver version 314.21, CUDA version 5.0, compute capability 3.0, 3072MB, 2720MB available, 3021 GFLOPS peak)
3/22/2013 5:32:27 PM | | CUDA: NVIDIA GPU 1: GeForce GTX 460 (driver version 314.21, CUDA version 5.0, compute capability 2.1, 1024MB, 951MB available, 1025 GFLOPS peak)
3/22/2013 5:32:27 PM | | OpenCL: NVIDIA GPU 0: GeForce GTX 660 Ti (driver version 314.21, device version OpenCL 1.1 CUDA, 3072MB, 2720MB available, 3021 GFLOPS peak)
3/22/2013 5:32:27 PM | | OpenCL: NVIDIA GPU 1: GeForce GTX 460 (driver version 314.21, device version OpenCL 1.1 CUDA, 1024MB, 951MB available, 1025 GFLOPS peak)
3/22/2013 5:32:27 PM | Poem@Home | Found app_config.xml
3/22/2013 5:32:27 PM | GPUGRID | Found app_config.xml
3/22/2013 5:32:27 PM | World Community Grid | Found app_config.xml
3/22/2013 5:32:27 PM | | Config: use all coprocessors
3/22/2013 5:32:27 PM | World Community Grid | Config: excluded GPU. Type: all. App: hcc1. Device: 0
3/22/2013 5:32:27 PM | Poem@Home | Config: excluded GPU. Type: all. App: poemcl. Device: 1
3/22/2013 5:32:27 PM | | Config: don't compute while iRacingSim.exe is running
3/22/2013 5:32:27 PM | | Config: don't compute while iRacingSim64.exe is running
3/22/2013 5:32:27 PM | | Config: don't compute while TmForever.exe is running
3/22/2013 5:32:27 PM | | Config: don't compute while TmForeverLauncher.exe is running
3/22/2013 5:32:27 PM | | Config: don't compute while NotepadTest01.exe is running
3/22/2013 5:32:27 PM | | Config: don't use GPUs while NotepadTest02.exe is running
3/22/2013 5:32:27 PM | rosetta@home | URL http://boinc.bakerlab.org/rosetta/; Computer ID 1605917; resource share 1
3/22/2013 5:32:27 PM | DrugDiscovery | URL http://boinc.drugdiscoveryathome.com/; Computer ID 13899; resource share 1
3/22/2013 5:32:27 PM | Poem@Home | URL http://boinc.fzk.de/poem/; Computer ID 125441; resource share 1
3/22/2013 5:32:27 PM | The Lattice Project | URL http://boinc.umiacs.umd.edu/; Computer ID 80111; resource share 1
3/22/2013 5:32:27 PM | boincsimap | URL http://boincsimap.org/boincsimap/; Computer ID 221424; resource share 1
3/22/2013 5:32:27 PM | superlinkattechnion | URL http://cbl-boinc-server2.cs.technion.ac.il/superlinkattechnion/; Computer ID 70369; resource share 1
3/22/2013 5:32:27 PM | Docking | URL http://docking.cis.udel.edu/; Computer ID 110448; resource share 1
3/22/2013 5:32:27 PM | MindModeling@Beta | URL http://mindmodeling.org/; Computer ID 21995; resource share 1
3/22/2013 5:32:27 PM | Quake-Catcher Network | URL http://qcn.stanford.edu/sensor/; Computer ID 20611; resource share 1
3/22/2013 5:32:27 PM | ralph@home | URL http://ralph.bakerlab.org/; Computer ID 27691; resource share 1
3/22/2013 5:32:27 PM | SETI@home | URL http://setiathome.berkeley.edu/; Computer ID 6930498; resource share 0
3/22/2013 5:32:27 PM | DNA@Home | URL http://volunteer.cs.und.edu/dna/; Computer ID not assigned yet; resource share 100
3/22/2013 5:32:27 PM | WUProp@Home | URL http://wuprop.boinc-af.org/; Computer ID 47890; resource share 1
3/22/2013 5:32:27 PM | Cosmology@Home | URL http://www.cosmologyathome.org/; Computer ID 163889; resource share 1
3/22/2013 5:32:27 PM | GPUGRID | URL http://www.gpugrid.net/; Computer ID 126725; resource share 1
3/22/2013 5:32:27 PM | RNA World | URL http://www.rnaworld.de/rnaworld/; Computer ID 16705; resource share 1
3/22/2013 5:32:27 PM | World Community Grid | URL http://www.worldcommunitygrid.org/; Computer ID 2046930; resource share 187
3/22/2013 5:32:27 PM | World Community Grid | General prefs: from World Community Grid (last modified 17-Mar-2013 12:17:49)
3/22/2013 5:32:27 PM | World Community Grid | Host location: none
3/22/2013 5:32:27 PM | World Community Grid | General prefs: using your defaults
3/22/2013 5:32:27 PM | | Reading preferences override file
3/22/2013 5:32:27 PM | | Preferences:
3/22/2013 5:32:27 PM | | max memory usage when active: 3067.49MB
3/22/2013 5:32:27 PM | | max memory usage when idle: 3067.49MB
3/22/2013 5:32:27 PM | | max disk usage: 0.00GB
3/22/2013 5:32:27 PM | | max upload rate: 65536 bytes/sec
3/22/2013 5:32:27 PM | | (to change preferences, visit a project web site or select Preferences in the Manager)
3/22/2013 5:32:27 PM | | [work_fetch] Request work fetch: Prefs update
3/22/2013 5:32:27 PM | | [work_fetch] Request work fetch: Startup
3/22/2013 5:32:27 PM | | Not using a proxy
|
|
|
|
Hello: As JacobKlein says should work.
To ensure your app_config.xml fits all short tasks <name> can put two lines with each of their names is:
<app_config>
<app>
<name>acemd2</ name>
<name>acemdshort</ name>
<max_concurrent>4</ max_concurrent>
<gpu_versions>
<gpu_usage>.5</ gpu_usage>
<cpu_usage>1</ cpu_usage>
</gpu_versions>
</app>
</app_config>
With this configuration must be able to run two GPU tasks and assign each task a CPU for short (unless they change the names). Regards |
|
|
|
Hello: As JacobKlein says should work.
To ensure your app_config.xml fits all short tasks <name> can put two lines with each of their names is:
<app_config>
<app>
<name>acemd2</ name>
<name>acemdshort</ name>
<max_concurrent>4</ max_concurrent>
<gpu_versions>
<gpu_usage>.5</ gpu_usage>
<cpu_usage>1</ cpu_usage>
</gpu_versions>
</app>
</app_config>
With this configuration must be able to run two GPU tasks and assign each task a CPU for short (unless they change the names). Regards
Umm, as far as I know, you are NOT USING THE XML CORRECTLY.
Here's the documentation:
http://boinc.berkeley.edu/trac/wiki/ClientAppConfig
Each application needs to have its own <app> block. You are not supposed to put multiple <name> blocks within an <app> block.
A good starting point would be to
- use this code block below
- save it to your www.gpugrid.net project directory as a file called app_config.xml
- instruct BOINC to read it (by using Advanced -> Read config file, or by restarting BOINC)
- look for the message in the Event Log for the GPUGrid project that says "Found app_config.xml" to verify BOINC saw it
- then tweak only the <gpu_usage> and <cpu_usage> lines, to tell BOINC how much resources each application's tasks take
- instruct BOINC to read it again, any time you make a change to it
<app_config>
<app>
<name>acemdbeta</name>
<max_concurrent>9999</max_concurrent>
<gpu_versions>
<gpu_usage>1</gpu_usage>
<cpu_usage>0.001</cpu_usage>
</gpu_versions>
</app>
<app>
<name>acemdlong</name>
<max_concurrent>9999</max_concurrent>
<gpu_versions>
<gpu_usage>1</gpu_usage>
<cpu_usage>0.001</cpu_usage>
</gpu_versions>
</app>
<app>
<name>acemd2</name>
<max_concurrent>9999</max_concurrent>
<gpu_versions>
<gpu_usage>1</gpu_usage>
<cpu_usage>0.001</cpu_usage>
</gpu_versions>
</app>
<app>
<name>acemdshort</name>
<max_concurrent>9999</max_concurrent>
<gpu_versions>
<gpu_usage>1</gpu_usage>
<cpu_usage>0.001</cpu_usage>
</gpu_versions>
</app>
</app_config>
If you wanted 2 tasks to run on a single GPU, I'd recommend changing the <gpu_usage> and <cpu_usage> lines to say:
<gpu_usage>0.5</gpu_usage>
<cpu_usage>0.001</cpu_usage> |
|
|
|
Hello: It sure can put multiple labels <name>.
Naturally provided <gpu_usage> and <cpu_usage> parameters are the same for the aforementioned tasks.
In my case as short tasks using both names are
<name>acemd2</name>
<name>acemdshort</name>
So I cover the two variants.
For long I see interesting tasks execute more than one task per GPU.
<cpu_usage>0.001</cpu_usage> continued without understanding this configuration.
He says to use only one thousandth of CPU for each task, but in reality what will send the "priority" that the task is assigned by default to the OS (low, medium, high, etc ...)
Using Ubuntu 10.12-64bits not if Windows responds differently, but really what matters is what each one would work. Greetings. |
|
|
|
Carlesa, I know what I'm talking about, and your syntax is wrong. I've done some local testing on my machine to conclusively prove it, too.
Basically, by supplying multiple <name> tags within the same <app> block, the program only applies the requested <gpu_usage> and <cpu_usage> tags to the LAST <name> tag that was provided. The prior <name> tags are essentially ignored. You can prove it by testing this, yourself. Please don't spread incorrect information.
The correct syntax is the one that I've provided, where the different apps each have their own <app> block, and each <app> block only has 1 <name> tag.
Thanks,
Jacob |
|
|
|
I have tested it already. While watching Task Manager's Details tab, sorted by CPU descending, I see that the acemd process is never starved for CPU, even though other running CPU tasks are (at times) starved.
So the ACEMDs are still grabbing CPU time. Now the important question is: are they able to do this just at the right time to avoid the GPU running dry, i.e. does GPU performance suffer (I suppose so) and by how much? The latter would be needed for people to decide if this trade-off is worth it for them.
Watching GPU utilization, maybe averaging it, would be a nice indicator. Although the best performance indicator would be WU runtimes for similar tasks.
MrS
____________
Scanning for our furry friends since Jan 2002 |
|
|
|
From what I can tell (and I admittedly do need to do some more testing), on my quad-core hyper-threaded (so windows sees 8 CPUs) machine, here's what I see:
When the CPUs are under full load with other projects, a Long-Run NATHAN GPUGrid task gets about 86% GPU Load on my GTX 660 Ti FTW, while also using a full CPU core.
When the CPUs are not under load (ie: I have set BOINC to use 0.01 % of the processors), a Long-Run NATHAN GPUGrid task gets about 90% GPU Load on my GTX 660 Ti FTW, while also using a full CPU core.
Even though under full CPU load the ACEMD process isn't starved for CPU, I believe it is still "competing" for 2 things:
1) The process is running full blast, along with another process, hyper-threaded, on the same core.
2) If the number of active processes is larger than the 8 CPUs windows sees, there's context swapping that decreases performance.
So, there is a trade-off, as you say. I think the best way to determine how to maximize GPUGrid performance, while not sacrificing CPU task performance, is to test running the GPUGrid tasks, at various levels of BOINC x% of the processors, and then comparing task run times. I haven't done this yet, and might not get around to it, as I believe that keeping the CPU busy outweighs slightly overloading the CPU and slightly sacrificing % GPU Load.
Hope that makes sense.
I'm due to get more memory for this machine in a week or so, which will help me to even better ensure that the 8 CPU slots remain filled. I *might* get around to doing the tests mentioned above, maybe.
PS: I find it a bit odd that, when a Long-Run NATHAN task is processing on the GTX 660 Ti, the ACEMD process uses a full CPU, yet when a Long-Run NATHAN task is processing on the GTX 460, the ACEMD process doesn't appear to use much CPU at all. Does that really depend on the GPU card's architecture? If so, then it's great that I'm using 0.001 <cpu_usage>; better to assume it's NOT using a CPU, than to assume it is. |
|
|
Dylan Send message
Joined: 16 Jul 12 Posts: 98 Credit: 386,043,752 RAC: 0 Level
Scientific publications
|
I haven't really gone through this thread, so I don't know if someone covered this or not, however it seems that many workunits use a bit more of CPU time then one core or thread. Therefore, I leave open an additional core so that any of the workunits, whether they are CPU or GPU based, won't compete for time.
Here is my configuration:
I have 8 cores(i7-3820, hyperthreaded), and two 670's.
Furthermore, I tell BOINC to use 75% of the processor, or 5 cores, and 100% CPU time. I also use the Swan sync variable that allows one core per GPU, so then 2 more cores are allocated to the 670's. This means I have one core not being used, however it seems that BOINC still uses it, as my total CPU usage is 97%, not 87.5%, like it should be if I had one core still free.
Looking in Task Manager, I see that both the GPUGRID workunits, and the CPU workunits (World Community Grid Clean Energy Project)use somewhere around 13.4-13.8 CPU time, which is more than one core.
To conclude, a one core per workunit configuration, whether the workunits are a CPU or GPU one, doesnt' always mean that the workunits won't have to compete, and another solution might be needed, such as having 1 unused core to make sure every workunit gets as much CPU time that it needs.
Sorry if this seemed confusing, if you have questions, please ask and I will try to answer them. I also want to add that I didn't check the GPU usage to see if this solution made any difference in GPU performance. |
|
|
OperatorSend message
Joined: 15 May 11 Posts: 108 Credit: 297,176,099 RAC: 0 Level
Scientific publications
|
Thanks to both Carlesa25 and JacobKlein I managed to coax my machine with the 2x GTX 590s to process 2 WUs per GPU.
But there is a problem. And so far it has something to do with Heisenberg's Uncertainty principle because it only happens when I'm not looking.
To whit, everything is crunching along just fine with 8 WUs. I log off and come back later to find that several of the previously happy WUs that were more than half way through (in most cases) have decided they are finished and they upload without the 'output file' that can't be found.
I have gone back to crunching just one WU per GPU until I have time to investigate further.
Hey, it was worth a shot....
Operator
____________
|
|
|
skgivenVolunteer moderator Volunteer tester
Send message
Joined: 23 Apr 09 Posts: 3968 Credit: 1,995,359,260 RAC: 0 Level
Scientific publications
|
For stability reasons I almost always tell Boinc to crunch using one or two less CPU's than the processor has, and usually dedicate one to the GPU. So for an 8thread system with a GPU, I tell Boinc to use 75% of the CPU's (6).
If testing app_config with more than 1 GPUGrid task per GPU, I suggest you don't use the CPU for anything else for a few days, to properly test stability. Then add 2threads/cores, then another 2, but don't saturate the CPU.
____________
FAQ's
HOW TO:
- Opt out of Beta Tests
- Ask for Help |
|
|
|
For the record, I've had no stability problems saturating the CPU, telling BOINC to use 100% of the processors (all 8/8) while using a <cpu_usage> value of 0.001 for the GPUGrid applications. So, for me, 8 other CPU tasks run just fine alongside the GPUGrid GPU task.
I haven't tried doing multiple GPUGrid tasks on the same GPU yet. |
|
|
OperatorSend message
Joined: 15 May 11 Posts: 108 Credit: 297,176,099 RAC: 0 Level
Scientific publications
|
For stability reasons I almost always tell Boinc to crunch using one or two less CPU's than the processor has, and usually dedicate one to the GPU. So for an 8thread system with a GPU, I tell Boinc to use 75% of the CPU's (6).
If testing app_config with more than 1 GPUGrid task per GPU, I suggest you don't use the CPU for anything else for a few days, to properly test stability. Then add 2threads/cores, then another 2, but don't saturate the CPU.
If this was a response to my post (not sure if it was meant for me or JacobKlein), I leave all 24 threads available to GPU support. I realize this makes me a bit of a slacker in the 'multi-tasking' area, but I had some difficulty early on when first running GPUGrid and other projects together, so I just focused on GPUGrid.
I am a bit disappointed that I can't run more than one GPUGrid long WU per GPU without things going sideways, and I'm not that familiar with the error logs to conduct a post mortem. So it will take a while to figure out.
Operator
____________
|
|
|
|
Carlesa, I know what I'm talking about, and your syntax is wrong. I've done some local testing on my machine to conclusively prove it, too.
Basically, by supplying multiple <name> tags within the same <app> block, the program only applies the requested <gpu_usage> and <cpu_usage> tags to the LAST <name> tag that was provided. The prior <name> tags are essentially ignored. You can prove it by testing this, yourself. Please don't spread incorrect information.
The correct syntax is the one that I've provided, where the different apps each have their own <app> block, and each <app> block only has 1 <name> tag.
Thanks,
Jacob
Hello Jacob: I do not intend to create a sterile polemic, simply confirm that my syntax is correct, you can put multiple labels app_config.xml <name> and reads well, is easy to verify by putting false names, for example.
I works perfectly with:
<name>acemd2</name>
<name>acemdshort</name>
I detect changes as short assignment of a name or another and applies the settings that I have in my app_config.xml.
Let everyone draw their conclusions. Greetings. |
|
|
|
Carlesa:
This isn't about drawing conclusions. It's about proving that your syntax is wrong, and showing that if you put 2 name tags in a row, the first ones are ignored.
I didn't want to do this, but I feel I must, in the name of science. I encourage you to use the steps here to prove that what I am saying is correct. Here goes:
I am currently processing a GPUGrid.net task, of type "acemdlong". In the BOINC Manager, it currently says:
"Running (0.001 CPUs + 1 NVIDIA GPU (device 0))"
... because of my current app_config.xml file.
... But let's say I wanted to change those settings.
If I change the app_config.xml file in the \projects\www.gpugrid.net directory, and I change it to:
<app_config>
<app>
<name>acemdlong</name>
<name>acemdbeta</name>
<max_concurrent>9999</max_concurrent>
<gpu_versions>
<gpu_usage>1</gpu_usage>
<cpu_usage>0.002</cpu_usage>
</gpu_versions>
</app>
</app_config> ... and close BOINC, and restart BOINC, the end result is:
"Running (0.001 CPUs + 1 NVIDIA GPU (device 0))"
The CPU usage did NOT change, because the syntax is WRONG.
If I change it to:
<app_config>
<app>
<name>acemd2</name>
<name>acemdlong</name>
<name>acemdbeta</name>
<max_concurrent>9999</max_concurrent>
<gpu_versions>
<gpu_usage>1</gpu_usage>
<cpu_usage>0.003</cpu_usage>
</gpu_versions>
</app>
</app_config> ... and close BOINC, and restart BOINC, the end result is:
"Running (0.001 CPUs + 1 NVIDIA GPU (device 0))"
The CPU usage did NOT change, because the syntax is WRONG.
If I change it to:
<app_config>
<app>
<name>acemd2</name>
<name>acemdbeta</name>
<name>acemdlong</name>
<max_concurrent>9999</max_concurrent>
<gpu_versions>
<gpu_usage>1</gpu_usage>
<cpu_usage>0.004</cpu_usage>
</gpu_versions>
</app>
</app_config> ... and close BOINC, and restart BOINC, the end result is:
"Running (0.004 CPUs + 1 NVIDIA GPU (device 0))"
The CPU usage DID CHANGE, but only because the last <name> tag was my app's name.
If I change it to:
<app_config>
<app>
<name>acemdlong</name>
<max_concurrent>9999</max_concurrent>
<gpu_versions>
<gpu_usage>1</gpu_usage>
<cpu_usage>0.005</cpu_usage>
</gpu_versions>
</app>
</app_config> ... and close BOINC, and restart BOINC, the end result is:
"Running (0.005 CPUs + 1 NVIDIA GPU (device 0))"
The CPU usage DID CHANGE, because the syntax is correct.
Here's the CORRECT SYNTAX for the GPUGrid.net project's app_config.xml file, per the documentation found here:
http://boinc.berkeley.edu/wiki/Client_configuration#Application_configuration
<app_config>
<app>
<name>acemdbeta</name>
<max_concurrent>9999</max_concurrent>
<gpu_versions>
<gpu_usage>1</gpu_usage>
<cpu_usage>0.001</cpu_usage>
</gpu_versions>
</app>
<app>
<name>acemdlong</name>
<max_concurrent>9999</max_concurrent>
<gpu_versions>
<gpu_usage>1</gpu_usage>
<cpu_usage>0.001</cpu_usage>
</gpu_versions>
</app>
<app>
<name>acemd2</name>
<max_concurrent>9999</max_concurrent>
<gpu_versions>
<gpu_usage>1</gpu_usage>
<cpu_usage>0.001</cpu_usage>
</gpu_versions>
</app>
<app>
<name>acemdshort</name>
<max_concurrent>9999</max_concurrent>
<gpu_versions>
<gpu_usage>1</gpu_usage>
<cpu_usage>0.001</cpu_usage>
</gpu_versions>
</app>
</app_config>
... and then you can adjust the <max_concurrent> and <gpu_usage> and <cpu_usage> values to whatever you desire, for each of the 4 different apps.
I still recommend the values:
<max_concurrent>9999</max_concurrent>
<gpu_usage>1</gpu_usage>
<cpu_usage>0.001</cpu_usage>
Regards,
Jacob |
|
|
|
Exactly. The whole purpose of the nested XML syntax is to make it absolutely clear which settings apply to which application. Everything from
<app>
...
</app>
has to be bracketed together - with a name, and one or more settings.
If you want to apply more settings to more applications, you have to add a second <app> ... </app> block.
You can test that even more easily, by using BOINC v7.0.54 or later, and re-reading config files while BOINC is running - no need to keep stopping and starting BOINC's settings. |
|
|
|
I have tested it already. While watching Task Manager's Details tab, sorted by CPU descending, I see that the acemd process is never starved for CPU, even though other running CPU tasks are (at times) starved.
So the ACEMDs are still grabbing CPU time. Now the important question is: are they able to do this just at the right time to avoid the GPU running dry, i.e. does GPU performance suffer (I suppose so) and by how much? The latter would be needed for people to decide if this trade-off is worth it for them.
Watching GPU utilization, maybe averaging it, would be a nice indicator. Although the best performance indicator would be WU runtimes for similar tasks.
MrS
So, there is a trade-off, as you say. I think the best way to determine how to maximize GPUGrid performance, while not sacrificing CPU task performance, is to test running the GPUGrid tasks, at various levels of BOINC x% of the processors, and then comparing task run times. I haven't done this yet, and might not get around to it, as I believe that keeping the CPU busy outweighs slightly overloading the CPU and slightly sacrificing % GPU Load.
Richard,
I have concluded some actual performance testing using my eVGA GTX 660 Ti 3GB FTW. Here is what I found:
========================================================================
Running with no other tasks (every other BOINC task and project was suspended, so the single GPUGrid task was free to use up the whole CPU core):
Task: 6669110
Name: I23R54-NATHAN_dhfr36_3-17-32-RND2572_0
URL: http://www.gpugrid.net/result.php?resultid=6669110
Run time (sec): 19,085.32
CPU time (sec): 19,043.17
========================================================================
Running at <cpu_usage>0.001</cpu_usage>, BOINC set at 100% processors, along with a full load of other GPU/CPU tasks:
Task: 6673077
Name: I11R21-NATHAN_dhfr36_3-18-32-RND5041_0
URL: http://www.gpugrid.net/result.php?resultid=6673077
Run time (sec): 19,488.65
CPU time (sec): 19,300.91
Task: 6674205
Name: I25R97-NATHAN_dhfr36_3-13-32-RND4438_0
URL: http://www.gpugrid.net/result.php?resultid=6674205
Run time (sec): 19,542.35
CPU time (sec): 19,419.97
Task: 6675877
Name: I25R12-NATHAN_dhfr36_3-19-32-RND6426_0
URL: http://www.gpugrid.net/result.php?resultid=6675877
Run time (sec): 19,798.77
CPU time (sec): 19,606.33
========================================================================
So, as expected, there is some minor CPU contention whilst under full load, but not much (Task Run time is maybe ~3% slower). It's not affected much because the ACEMD process actually runs at a higher priority than other BOINC task processes, and therefor, are never starved for CPU, and are likely only minorly starved for contention during CPU process context switching.
This, to me, is conclusive reasoning to keep my CPUs loaded, by using the following settings:
BOINC setting "% of the Processors": 100%
GPUGrid app_config <cpu_usage> setting: 0.001
Kind regards,
Jacob |
|
|
skgivenVolunteer moderator Volunteer tester
Send message
Joined: 23 Apr 09 Posts: 3968 Credit: 1,995,359,260 RAC: 0 Level
Scientific publications
|
Your findings apply to NATHAN_dhfr36 WU's...
____________
FAQ's
HOW TO:
- Opt out of Beta Tests
- Ask for Help |
|
|
|
Ah, so are you saying I should test against the Short Run units also, to see if I get similar results? |
|
|
|
Your findings apply to NATHAN_dhfr36 WU's...
Well, to further test against short units, I changed my account settings to only receive "Short 4.2" units.
Here are the results:
========================================================================
Running with no other tasks (every other BOINC task and project was suspended, so the single GPUGrid task was free to use up the whole CPU core):
Task: 6678769
Name: I1R110-NATHAN_RPS1_respawn3-10-32-RND4196_2
URL: http://www.gpugrid.net/result.php?resultid=6678769
Run time (sec): 8,735.43
CPU time (sec): 8,710.61
Task: 6678818
Name: I1R42-NATHAN_RPS1_respawn3-12-32-RND1164_1
URL: http://www.gpugrid.net/result.php?resultid=6678818
Run time (sec): 8,714.75
CPU time (sec): 8,695.18
========================================================================
Running at <cpu_usage>0.001</cpu_usage>, BOINC set at 100% processors, along with a full load of other GPU/CPU tasks:
Task: 6678817
Name: I1R436-NATHAN_RPS1_respawn3-13-32-RND2640_1
URL: http://www.gpugrid.net/result.php?resultid=6678817
Run time (sec): 8,949.63
CPU time (sec): 8,897.27
Task: 6679874
Name: I1R414-NATHAN_RPS1_respawn3-7-32-RND6785_1
URL: http://www.gpugrid.net/result.php?resultid=6679874
Run time (sec): 8,828.17
CPU time (sec): 8,786.48
Task: 6679828
Name: I1R152-NATHAN_RPS1_respawn3-5-32-RND8187_0
URL: http://www.gpugrid.net/result.php?resultid=6679828
Run time (sec): 8,891.22
CPU time (sec): 8,827.11
========================================================================
So, again, as expected, there is only slight contention while under full CPU load, because the ACEMD process actually runs at a higher priority than other BOINC task processes, and therefor, are never starved for CPU, and are likely only minorly starved for contention during CPU process context switching.
If you'd like me to perform some other test, please let me, and I'll see if I can try it.
To maximize my crunching efforts, I still plan on keeping my settings of:
BOINC setting "% of the Processors": 100%
GPUGrid app_config <cpu_usage> setting: 0.001
Kind regards,
Jacob |
|
|
skgivenVolunteer moderator Volunteer tester
Send message
Joined: 23 Apr 09 Posts: 3968 Credit: 1,995,359,260 RAC: 0 Level
Scientific publications
|
Thanks Jacob,
That's a fairly solid set of results for Nathan's present WU's, Long and Short.
I'm not seeing any other task types at present, so it acts as a good guide, but Noelia, Gianni and Toni WU's would also need to be tested as and when they arrive.
The driver might have a slight influence (up to 3% with older drivers tending to be faster - more noticeable on lesser systems).
A lesser processor would also have a negative impact as would slower RAM and disk I/O. The CPU type and the way the CPU handles multiple threads might also have a small impact, as might the PCIE bus. Together these things could add up (5 or 10%). More of a concern if you have multiple GPU's in the one system.
From what the researchers said about the present apps I expected something similar, but wouldn't be surprised if there is a slightly increased difference (5 to 8%) when new tasks arrive.
The super-scalar cards are now better catered for, so perhaps there is more of a difference with the older CC2.0 cards?
Last time I looked there was still a large (11%+) performance difference between XP/Linux and Win Vista/7/8. On the newer Win servers it was less (2008/2008R2/2012 - 3 to 8%).
The CPU apps that are running can have a massive or minimal impact on GPU performance. You really don't want to be running 8 climate models and a GPU task, or perhaps a full suite of WCG's CEP tasks.
____________
FAQ's
HOW TO:
- Opt out of Beta Tests
- Ask for Help |
|
|
|
Thanks Jacob,
That's a fairly solid set of results for Nathan's present WU's, Long and Short.
I'm not seeing any other task types at present, so it acts as a good guide, but Noelia, Gianni and Toni WU's would also need to be tested as and when they arrive. You're welcome. When I see tasks of type Noelia, Gianni, or Toni, I'll see if I can try to isolate some results on them, but I'm betting the results will be the same.
The CPU apps that are running can have a massive or minimal impact on GPU performance. You really don't want to be running 8 climate models and a GPU task, or perhaps a full suite of WCG's CEP tasks. I don't agree. From what I am seeing, performance wise, it doesn't matter what type of CPU tasks are running; the Below Normal Windows priority given to the ACEMD process ensures that it gets the CPU whenever it wants it. If the CPU tasks somehow ran at a higher Windows priority than Low, then that might make a difference. Are you suggesting I should setup a test where I run a GPUGrid GPU task alongside 8 CPU tasks of a certain type? I really don't think it would make a difference.
-- Jacob |
|
|
skgivenVolunteer moderator Volunteer tester
Send message
Joined: 23 Apr 09 Posts: 3968 Credit: 1,995,359,260 RAC: 0 Level
Scientific publications
|
The aforementioned CPU task types are quite extreme; require massive I/O. So much so that they interfere with their own performances never mind other tasks. The RunTime to CPU Time delta tends to expand rapidly with such tasks, and in the past has impacted upon GPU performance for several projects (albeit more so the OpenCL apps) and other CPU projects. Anything that hammers the CPU kernel, memory and hard drive will have a negative impact on almost any crunching. It's my understanding the disk I/O is OS controlled and high priority irrespective of the app requiring disk I/O.
____________
FAQ's
HOW TO:
- Opt out of Beta Tests
- Ask for Help |
|
|
|
You really don't want to be running 8 climate models and a GPU task, or perhaps a full suite of WCG's CEP tasks.
The aforementioned CPU task types are quite extreme; require massive I/O. So much so that they interfere with their own performances never mind other tasks. The RunTime to CPU Time delta tends to expand rapidly with such tasks, and in the past has impacted upon GPU performance for several projects (albeit more so the OpenCL apps) and other CPU projects. Anything that hammers the CPU kernel, memory and hard drive will have a negative impact on almost any crunching. It's my understanding the disk I/O is OS controlled and high priority irrespective of the app requiring disk I/O. Could you please be more specific? I'd like to test your theory if I could.
You mention "8 climate models".. Does that mean project "climateprediction.net" and if so does it mean any specific app? Or are all of their apps intensive?
You mention "WCG CEP"... Does that mean project "World Community Grid" and if so does it mean app "cep2" which is "The Clean Energy Project - Phase 2"? |
|
|
skgivenVolunteer moderator Volunteer tester
Send message
Joined: 23 Apr 09 Posts: 3968 Credit: 1,995,359,260 RAC: 0 Level
Scientific publications
|
This is going way off topic, and is more to do with other projects than GPUGRID!
My theory was fact, but might no longer be the case; apps and WU's get improved all the time, such as the apps for here which now perform much better for the super scalar cards - It use to be the case that CC2.0 was much better than CC2.1. That's no longer the case, and when the apps development/testing is complete would need to be looked at again.
You mention "8 climate models".. Does that mean project "climateprediction.net" and if so does it mean any specific app? Or are all of their apps intensive?
Yes, I mean 8 climate models from climateprediction.net. I don't know what apps/models are currently available, if any, and I've recently had mixed results running WU's (lots of failures), as have most others. Note there are some site issues.
You mention "WCG CEP"... Does that mean project "World Community Grid" and if so does it mean app "cep2" which is "The Clean Energy Project - Phase 2"?
Yes, phase 2 of the CEP supported by WCG. Haven't picked up any CEP2 tasks recently, so they might be out of work? You could check/ask in their forums. It's possible that recent development in the app has changed things but in the past when I ran lots of these tasks it was noticeable (I could hear the hard drive clicking away). WCG did a lot to support that project. You have to specifically select the project, set the number of tasks to run (default is 1). Plenty or RAM and LAIM on is recommended,
See The Clean Energy Project - Phase 2 technical project details and CEP2 Thread List and the app_config CEP2 thread.
Note that your LGA1366 CPU and motherboard supports 3 Memory Channels. This helps with such projects. So does fast memory, and a SATA 3 drive. In many ways your rigs design is better design than an i7-3770K based system (the main disadvantage is CPU/motherboard performance/power).
Good luck,
____________
FAQ's
HOW TO:
- Opt out of Beta Tests
- Ask for Help |
|
|
|
You're right, we're off topic, and I apologize. I greatly appreciate your inputs, and if I manage to perform some tests on those applications, I'll reply privately, and I'll consider making a public post.
Back to the original "app_config.xml" topic, until I have any conclusive proof/reason to believe otherwise...
To maximize my crunching efforts, I'm using and recommending:
BOINC settings:
% of the processors: 100%
% CPU time: 100%
app_config settings for each of the 4 GPUGrid projects:
<max_concurrent>9999</max_concurrent>
<gpu_usage>1</gpu_usage>
<cpu_usage>0.001</cpu_usage>
Best of luck,
Jacob |
|
|
|
FWIW you can do away with the max_concurrent tag for running GPU tasks. It's only needed when running CPU tasks. The gpu_usage tag controls how many tasks each GPU uses. |
|
|
|
Through my testing, I have been able to conclude that it DOES have an affect even on GPU tasks. ie: If you specify <max_concurrent> of 1 for a given GPU app type, it will only run 1, regardless of having <gpu_usage> of 0.5 or less. So, the setting DOES apply to GPU apps; feel free to test and verify.
I understand that it still appears to work even without setting a <max_concurrent> value, but... the documentation doesn't say that it's optional.
If that tag is optional, or if there are default values for tags not specified by the user, then the documentation should say so.
As it is, it doesn't say, and so I assume that it'll use whatever the project chooses as its default, unless the user specifies otherwise. And so, I explicitly specify otherwise, 9999.
http://boinc.berkeley.edu/wiki/Client_configuration#Application_configuration
- Jacob |
|
|
|
Thanks for your effort, Jacob!
That ~3% hit in GPU performance is a number hard enough for me to use as a future guideline. I wouldn't expect this value to change significantly upon the various changes SK mentioned. And for most other CPU tasks this value should apply.. let's call them well-behaved. There may be tasks which are much more demanding (e.g. Climateprediction), but these are the exception rather than the norm.
However, there should be an important trend: the performance hit should grow, the faster the GPU becomes, as it would need CPU support more frequently (-> more interruptions) and a similar delays waste more GPU power (this could actually already be accounted for by measuring the performance hit in %).
And put the other way around: the slower a GPU, the less important the CPU support should be. So people with smaller GPUs can feel free to use their CPUs elsewhere.
And if you're up for more tests there's one thing I think is missing: a comparison between 7 CPU tasks and 8, in addition to comparing to 0 CPU tasks. You may find the same 3%, which would make the choice tougher: my GTX660Ti is good for ~324k RAC crunching long-runs, so 3% less would cost me 9.7k RAC. That's about what a fast CPU can achieve running well-paying projects.. but nowhere near the throughput of a single virtual core (whose companion is already occupied).
MrS
____________
Scanning for our furry friends since Jan 2002 |
|
|
|
I will probably perform your requested test sometime soon. Right now, though, I'm testing running 2 tasks at the same time on the same GPU, and actually having some success.
When I have results ready, I think I'll create a new thread, so that posts to this thread can remain related to app_config. |
|
|
|
The previous result was a speedup of ~5%.. let's see what you get!
MrS
____________
Scanning for our furry friends since Jan 2002 |
|
|
|
The thread that contains my performance tuning can be found here:
http://www.gpugrid.net/forum_thread.php?id=3331
========================================================================
As I mentioned before:
To maximize my crunching efforts, I'm using and recommending:
BOINC settings:
% of the processors: 100%
% CPU time: 100%
app_config settings for each of the 4 GPUGrid projects:
<max_concurrent>9999</max_concurrent>
<gpu_usage>1</gpu_usage>
<cpu_usage>0.001</cpu_usage>
I'm still testing on "doubling-up" GPU tasks on a single GPU; if you wanted to do this, you'd use:
<gpu_usage>0.5</gpu_usage>
Best of luck,
Jacob |
|
|
|
FYI:
Per Toni (a project administrator), because of application and validator problems, I was told to disable running 2-at-a-time. So I have suspended my testing/research, and have put <gpu_usage> to 1, in the app_config.xml file.
http://www.gpugrid.net/forum_thread.php?id=3332#29425
Regards,
Jacob Klein |
|
|
|
FYI:
Per Toni (a project administrator), because of application and validator problems, I was told to disable running 2-at-a-time. So I have suspended my testing/research, and have put <gpu_usage> to 1, in the app_config.xml file.
http://www.gpugrid.net/forum_thread.php?id=3332#29425
Regards,
Jacob Klein
I have solved the problem I was having where Nathan tasks were not processing correctly on my machine.
The problem was completely unrelated to the app_config.xml file.
Details here: http://www.gpugrid.net/forum_thread.php?id=3332&nowrap=true#29894
So, we can resume app_config testing (including 2-tasks-on-1-GPU).
I still recommend using the app_config.xml file that is in this post:
http://www.gpugrid.net/forum_thread.php?id=3319&nowrap=true#29216
... and I only recommend trying 2-tasks-on-1-GPU if you are running GPUGrid on GPUs that have 2GB or more RAM; if that's the case, you might try using <gpu_usage> value of 0.5 in your app_config.xml file, to see if GPU Load increases (by using GPU-Z) and throughput increases (by looking at task Run Times).
Thanks,
Jacob |
|
|
|
i know but i want use 87% 1st wu and 13% 2nd wu , is that possible ? |
|
|
|
If you are asking if you can tell BOINC to only use a specified portion of a GPU for each of the tasks that are running on the GPU, then answer is no.
You can only use <gpu_usage>, to have BOINC determine how many tasks to run on a single GPU. You cannot specify that certain tasks should be run more of the time.
Regards,
Jacob |
|
|
|
thx for the reply, very sad, what i have to do with this saved power, i dont want to slow down my ending times of a wu ?
Just thought , can i run a second instance of boinc in the same inviroment and start a second gpugrid instance ???
Or is there a way to start a command line option to run gpugrid wus ? |
|
|
|
Thanks for asking the same thing in the other thread, so that I jsut wrote about the same as Jacob over here..
Regarding your other questions: it might be possible if you could launch the 2nd task at lower priority, then elevate it to normal when it becomes the 1st one (otherwise performance will suffer from CPU projects). I don't know how to do this, though. Except modifying BOINC yourself.
MrS
____________
Scanning for our furry friends since Jan 2002 |
|
|
|
There is a software on this site : BoincTasks
Where u can adjust the priority of the tasks, allready installed yet, but still trying.
i thought wrong, there is no adjustment.
I will try Windows Task Manager...no gpu usage change by changing the priority with windows. clueless :( |
|
|
|
Yeah, but you'd have to assign different priorities to tasks of the same name, and switch priority while the task is running. You could probably ask the developer to include such functionality, I don't suppose it's already there.
MrS
____________
Scanning for our furry friends since Jan 2002 |
|
|
|
As far as I have seen, a single task will only use "so much" of the GPU's "Usage" or "Load".
It's normal for GPU "Usage" or "Load" to vary, per app, and per project. I've seen some cases where the task makes it 99% (some SETI tasks), some where it's around 80-90% (Nathans here at GPUGrid), and some where it's quite low like 40% (POEM tasks).
To increase a GPU's "Usage" or "Load", so far as I know, your options are:
- Free up CPU resources, so the GPU is never waiting on the CPU to help it get a kernel of work started/ran.
- Run more tasks at once on the GPU, if possible |
|
|
flashawkSend message
Joined: 18 Jun 12 Posts: 297 Credit: 3,572,627,986 RAC: 0 Level
Scientific publications
|
I thought a GPU used some of it's own processing power for house keeping purposes, I've noticed when a wu breaks, the GPU will shoot up to 100% while the memory controller goes to 0%. So the more the data is being pumped through the GDDR memory, the more the GPU usage will lower slightly, amongst other things. |
|
|
|
ok, i will give the gpu a full cpu and see what happens next.
No effect, still the same gpu usage...
we must be waiting for a solution...
so long... |
|
|
skgivenVolunteer moderator Volunteer tester
Send message
Joined: 23 Apr 09 Posts: 3968 Credit: 1,995,359,260 RAC: 0 Level
Scientific publications
|
GPUGRID WU's usually use the GPU at 98 to 99% when running on Linux, XP or a 2003 server.
Utilization usually only drops on WDDM operating system (Vista, W7, W8, 2008 and 2013 Windows servers). On 2008 server it's slightly less (~5% instead of 11% with W7 last time I measured it) but different system architectures have different bottlenecks.
There are lots of other little things you can do (setting tweaks) to reduce the system overhead/maximize GPU performance; disable Aero, set your systems performance settings to adjust for best performance, disable unnecessary startup apps, use faster system memory, a SSD (though it might not last several years), a RAM drive or use a secondary drive for Boinc, use faster RAM (2133/2400 rather than 1333/1600), OC the CPU slightly, OC the GPU (especially the GDDR, as this should increase GPU usage), make sure it's using PCIE X16 as opposed to X8 or X4, use an iGPU for display, set the GPU to prefer maximum performance, increase the fan speed so that the GPU stays cooler, boosts well and doesn't downclock, use a better PSU (which apparently aids the Boost and keeps the system cooler), make sure your GPU is running at PCIE3 rather than dropping down to PCIE2 because your other GPU is PCIE2 only capable, stop using more than one CPU core/thread if your GPU and CPU time are not the same (or almost) - 33,047.69 vs 31,835.09 might represent 3.8% loss due to the CPU usage. Also, if you don't OC your CPU it's frequency isn't the same when one core is in use of 4 cores (3.5 vs 3.9GHz is an 11% CPU difference)...
____________
FAQ's
HOW TO:
- Opt out of Beta Tests
- Ask for Help |
|
|
WrendSend message
Joined: 9 Nov 12 Posts: 51 Credit: 522,101,722 RAC: 0 Level
Scientific publications
|
Hi, guys.
Having some issues getting multiple tasks to run per GPU.
I'd like (if possible) to have 2 tasks per GPU running of any and all of the GPUGrid tasks available. I'm not sure how to set this up regarding what the <name> value(s) should be currently in the app_config file.
If only one task/work unit type is available per value, I would prefer the long runs.
Any insight would be appreciated.
Thanks!
...
Edit: If there's some way to set this up globally in BOINC for all projects instead, that would be ideal. I already have BOINC set up to run 2 GPU tasks (presently 1 per GPU) simultaneously instead of the default 1.
To clarify: I'm trying to get a total of 4 GPU tasks to run simultaneously.
____________
My BOINC Cruncher, Minecraft Multiserver, Mobile Device Mainframe, and Home Entertainment System/Workstation: http://www.overclock.net/lists/display/view/id/4678036#
|
|
|
|
The <name> values can be found within your client_state.xml file, assuming you had previously downloaded a task for the application. Make sure that you do not touch/edit/save that file... just look at it, don't change it :)
Then the BOINC configuration for setting up the app_config can be found here:
http://boinc.berkeley.edu/wiki/Client_configuration
Finally, it sounds like you might be looking for the following (pasted below), which could be placed in your app_config.xml file within the gpugrid project folder. The gpu_usage of 0.5 indicates 2 tasks per GPU, and the cpu_usage of 0.667 means reserve 1 core when 2 tasks are running, and 2 cores when 3 tasks are running.
Good luck!
Jacob
<app_config>
<!-- Short runs (2-3 hours on fastest card) -->
<app>
<name>acemdshort</name>
<max_concurrent>0</max_concurrent>
<gpu_versions>
<gpu_usage>0.5</gpu_usage>
<cpu_usage>0.667</cpu_usage>
</gpu_versions>
</app>
<!-- Long runs (8-12 hours on fastest card) -->
<app>
<name>acemdlong</name>
<max_concurrent>0</max_concurrent>
<gpu_versions>
<gpu_usage>0.5</gpu_usage>
<cpu_usage>0.667</cpu_usage>
</gpu_versions>
</app>
<!-- ACEMD beta version -->
<app>
<name>acemdbeta</name>
<max_concurrent>0</max_concurrent>
<gpu_versions>
<gpu_usage>0.5</gpu_usage>
<cpu_usage>0.667</cpu_usage>
</gpu_versions>
</app>
</app_config>
|
|
|
WrendSend message
Joined: 9 Nov 12 Posts: 51 Credit: 522,101,722 RAC: 0 Level
Scientific publications
|
Thank you, sir! And thanks for the prompt reply. It's much appreciated.
I modified the other values you listed a little for my needs.
So far this seems to be working as desired. More tasks are being pulled in (downloaded) now, and the two GPU tasks I had running are now running on one GPU.
Rough estimate so far is that my total VRAM and VRAM per card will only be about 50% loaded running the 4 tasks simultaneously, which leaves more than enough head room even for gaming and the like. I even have the two cards in SLI configuration so their memory usage is mirrored.
Very awesome, and should give a significant boost to the total work per time I'm able to crunch on this computer.
Thanks again.
____________
My BOINC Cruncher, Minecraft Multiserver, Mobile Device Mainframe, and Home Entertainment System/Workstation: http://www.overclock.net/lists/display/view/id/4678036#
|
|
|
WrendSend message
Joined: 9 Nov 12 Posts: 51 Credit: 522,101,722 RAC: 0 Level
Scientific publications
|
Setup info:
I have two EVGA Titan Black Superclocked cards (6GB VRAM each). They are set to SLI in the Nvidia control panel for game rendering optimization. This causes their VRAM to be mirrored between the two cards so they can work on the same data at the same time.
In the Nvidia control panel I also have prefer maximum performance set to basically help keep the GPU clock rates up so that they're able to do more work per time.
I also have the C:\ProgramData\BOINC\cc_config.xml <use_all_gpus>1</use_all_gpus> value set to use each of my GPUs instead of just one.
OK, upon further testing:
With 4 GPUGrid tasks loaded in VRAM on each card (since the VRAM is mirrored), the VRAM is about 30% to 40% loaded on average, and with 2 tasks running per GPU, they're about 80% to 90% loaded on average (this is up about 20% from when only 1 task is being run per GPU). Additionally, the GPU clock rates seem to be much more consistently held at their higher stock boosted clock rate of 1125MHz. (I have a custom fan curve set for these cards to keep them well and cool and nowhere near throttling down.)
This should yield a significant performance increase in regard to the amount of overall work done per time.
...
I generally use 67% (8 of 12) CPU threads to crunch for BOINC, leaving 4 open for other tasks and programs. So I now simultaneously run 4 GPU tasks (GPUGrid) and 8 CPU tasks (World Community Grid).
So given that, what would be the optimal value for <cpu_usage>? I've tried 0.125, 0.25, and 0.5. I would prefer to leave enough room open on my CPU for other programs, but wouldn't mind using up to the equivalent of one additional thread as needed for the GPU tasks, so should I set this value to 0.25? But then again, would they even really use it? What is the default amount used for GPUGrid GPU tasks?
Thanks.
____________
My BOINC Cruncher, Minecraft Multiserver, Mobile Device Mainframe, and Home Entertainment System/Workstation: http://www.overclock.net/lists/display/view/id/4678036#
|
|
|
|
So given that, what would be the optimal value for <cpu_usage>?
There are philosophies:
1) Tell BOINC to run at 100% CPU, and then use the <cpu_usage> setting to have BOINC reserve cores when GPUGrid tasks are running.
... If you are going to go this route, then the answer depends on how many CPUs you want to consider budgeted by the GPUGrid tasks. Note, that the <cpu_usage> setting doesn't control how much of the CPU gets used -- instead, the setting controls how much CPU is "considered budgeted" due to the coprocessor (GPU/ASIC) task. I'd recommend setting it to 0.5, such that, when 4 GPUGrid tasks are running, BOINC will consider 2 CPUs budgeted. If you want to, instead, budget 1 CPU per GPUGrid task, then set <cpu_usage> to 1.0, such that at "Use 100% CPU" setting, 4 threads are reserved. On a single-GPU system, 1.0 might be a good option. But on a multi-GPU system, you'd want to set <cpu_usage> to free up at least 1 core total, or more, but maybe not as many cores as GPU tasks. For me, on my 3-GPU system [1 task per GPU], I use 0.667, such that, when 3 GPUGrid tasks are running, 2 cores are reserved.
Using this approach is cleaner than option 2 below, but is a bit tedious to change, since you have to change the app_config.xml and then restart BOINC to get the UI to show the CPU usage values correctly.
2) Use the "Use X% CPUs" setting to free up threads.
...I don't prefer this option, but it does end up being handier than having to edit an app_config.xml and restart BOINC. If you go this route, then you might set <cpu_usage> to 0.001, and then, just manually control how many threads are free, by manipulating the "Use X% CPUs" setting.
Long story short: For your 4-GPU-tasks, try <cpu_usage> of 0.5 (free up 2 cores) or 0.75 (free up 3 cores) or 1.0 (free up 4 cores). If you're looking for best GPUGrid GPU performance while also doing some CPU tasks, then use 1.0. |
|
|
WrendSend message
Joined: 9 Nov 12 Posts: 51 Credit: 522,101,722 RAC: 0 Level
Scientific publications
|
*1124MHz
...
Thanks, Jacob. You've given me some good info and things to try with this setup.
Will give 100%, 1.0 a try based on your suggestions and see how that goes.
____________
My BOINC Cruncher, Minecraft Multiserver, Mobile Device Mainframe, and Home Entertainment System/Workstation: http://www.overclock.net/lists/display/view/id/4678036#
|
|
|
|
You're welcome! Nice setup, by the way -- If you're ever interested in upgrading it, I wouldn't mind a used GPU at a decent price :) I'm pretty sure my MSI Frozr II fans are failing, but I'm still running GPUGrid on it, and having the other 2 EVGA rear-exhaust fans try to compensate :) It's literally a hot mess over here - All 3 GPUs at max fan with 70-80*C, and CPU at max fan at 86*C. This office is a sauna! |
|
|
Beyond Send message
Joined: 23 Nov 08 Posts: 1112 Credit: 6,162,416,256 RAC: 0 Level
Scientific publications
|
CPU at max fan at 86*C. This office is a sauna!
Notes on Intel Core i7-965:
Maximum operating temperature: 67.9°C
Maximum power dissipation: 230.14 Watt
Thermal Design Power: 130 Watt
Yikes, I'm surprised it's still running. We'll keep our fingers crossed :-)
|
|
|
|
Where did you get that info?
Everything I see shows that TjMax is 100*C, and I've only ever seen it go above 90*C whenever it was loaded and the fan didn't react quick enough.
I believe my CPU is actually:
Intel® Core™ i7-965 Processor Extreme Edition
http://ark.intel.com/products/37149/Intel-Core-i7-965-Processor-Extreme-Edition-8M-Cache-3_20-GHz-6_40-GTs-Intel-QPI
... factory overclocked from 3.2 GHz to 3.74 GHz (5 years ago by Dell).
Edit:
Ah, I see on that page:
"TCase: 67.9°C"
"Case Temperature is the maximum temperature allowed at the processor Integrated Heat Spreader (IHS)."
... I think that's different than the 80*C-90*C core temps that I'm monitoring. In fact, here's a page that explains some of the differences: http://www.intel.com/support/processors/sb/CS-033342.htm
Anyway, if we need to discuss this further, send me a PM. Otherwise, we should get back to the topic "app_config.xml" :) |
|
|
Beyond Send message
Joined: 23 Nov 08 Posts: 1112 Credit: 6,162,416,256 RAC: 0 Level
Scientific publications
|
Just thought I'd mention it. Here's the info I saw, Intel Core i7-965 Extreme Edition:
http://www.cpu-world.com/CPUs/Core_i7/Intel-Core%20i7%20Extreme%20Edition%20I7-965%20AT80601000918AA%20(BX80601965).html |
|
|
WrendSend message
Joined: 9 Nov 12 Posts: 51 Credit: 522,101,722 RAC: 0 Level
Scientific publications
|
For the external CPU temp (Tcase) I try and stay below 50 to 55 degrees C, and for the core temps below about 70 to 75 degrees C. Jacob, I think your CPU's thresholds are a little higher than mine, but you're still definitely pushing it a bit more than I would care to. Might want to look into upgrading your CPU cooler, or possibly down-clocking a little. It could be the GPUs' heat causing the CPU to heat up more, so might want to look into cooling the case inside down more too. I like to keep a well defined airflow path through my case that goes with convection; cool air in from the bottom front and side, and hot air out the back and rear top. So naturally I'm also a fan of the cards that exhaust heated air out the back instead of mixing it up inside the case.
As for my cards, I've only had them a couple of months now, so I will likely be hanging onto them for some time yet. Might even pick up a couple more if they're still available and I decide to go to the X99 build (i7-5960X, ASUS X99-E WS). I'll keep you in mind though if/when it comes time for them to find a new home. I might end up passing them down to some other friends of mine, if they're in the market for them. (I usually sell them at half the current going rate of new cards.) We shall see.
____________
My BOINC Cruncher, Minecraft Multiserver, Mobile Device Mainframe, and Home Entertainment System/Workstation: http://www.overclock.net/lists/display/view/id/4678036#
|
|
|
WrendSend message
Joined: 9 Nov 12 Posts: 51 Credit: 522,101,722 RAC: 0 Level
Scientific publications
|
(Would have edited my previous post, but just missed the cutoff time.)
...
Oh, by the way (and back on topic), I wanted to say that the 100%, 1.0 CPU usage settings seems to be going great so far. My only slight concern is CPU availability for other programs, but so far that doesn't seem likely to be an issue. Think I will stick with these settings for some time and see how it plays out. Thanks again.
____________
My BOINC Cruncher, Minecraft Multiserver, Mobile Device Mainframe, and Home Entertainment System/Workstation: http://www.overclock.net/lists/display/view/id/4678036#
|
|
|
|
Open Process Explorer to check the GPU tasks. You'll see they're really probably only using 15-25% of a core. So, by reserving 4 threads, you're actually allowing plenty of CPU to be readily available for any other tasks you might be doing (like browsing, Word, etc.). You *could* allocate that extra CPU towards CPU tasks (by using 0.001 <cpu_usage>), but then as I said, GPUGrid GPU tasks performance would suffer a bit.
It's all about tradeoffs. But Process Explorer will show you exactly how much CPU each of your acemd tasks is really using. |
|
|
WrendSend message
Joined: 9 Nov 12 Posts: 51 Credit: 522,101,722 RAC: 0 Level
Scientific publications
|
Yeah, not so much wondering about how much GPUGrid will use of those 4 threads, but more so some other programs I run could potentially want to load them up. (A few Minecraft servers, some games, media players, etc. all running at the same time.) But yeah, I think I should be fine. And if not, I can adjust things as needed later on. Right now I'm concentrating more on being patient enough to see how these settings play out.
Other than that though, I have noticed GPUGrid pulling in CPU tasks as well now which run on 12 CPUs. Some of those will somehow manage to run for a small fraction of a second before being suspended indefinitely (or maybe to run for another fraction of a second at some point) until I abort them. I'd rather not use up GPUGrid's bandwidth needlessly by downloading these tasks (nor get "their hopes up," thinking I'll be crunching them). Any ways for getting around this issue that you know of?
____________
My BOINC Cruncher, Minecraft Multiserver, Mobile Device Mainframe, and Home Entertainment System/Workstation: http://www.overclock.net/lists/display/view/id/4678036#
|
|
|
|
If you don't want certain applications from a project, go into the project's web settings and disable those applications for your account. |
|
|
WrendSend message
Joined: 9 Nov 12 Posts: 51 Credit: 522,101,722 RAC: 0 Level
Scientific publications
|
OK. Found the settings. Thanks.
Was thinking it was due to something I had done locally, since I hadn't noticed these tasks being pulled in before, but guess that's moot.
____________
My BOINC Cruncher, Minecraft Multiserver, Mobile Device Mainframe, and Home Entertainment System/Workstation: http://www.overclock.net/lists/display/view/id/4678036#
|
|
|
WrendSend message
Joined: 9 Nov 12 Posts: 51 Credit: 522,101,722 RAC: 0 Level
Scientific publications
|
After a bit more tweaking...
I decided to dedicate my GPUs to running 2 long work units each (provided they're available), as I think this will get the most out of my hardware.
GPUs are loaded more consistently at a higher 90% to 92%, and VRAM is loaded about 56% (approaching 3.5GB) with 4 WU in each card's VRAM since they're in SLI and mirrored. Fortunately the GPUs are holding at a decent 73 to 75 C°.
The higher GPU loads seem a little strange to me, as I would have thought they would have crunched through WU more similarly regardless of their total run times. As it is, it seems there's a bit more for them to work on at any given time with the long work unites, not just in total. Then again, this may just be due to the particular WU the GPUs are currently crunching.
Anyway, long story short, it looks like this will work out to be another slight performance improvement.
____________
My BOINC Cruncher, Minecraft Multiserver, Mobile Device Mainframe, and Home Entertainment System/Workstation: http://www.overclock.net/lists/display/view/id/4678036#
|
|
|
|
Hi Wrend,
I sent you a PM, as the best solution/method to improve / optimize crunching on GPUGRID I've tested is here :
http://www.gpugrid.net/forum_thread.php?id=2123&nowrap=true#16832
Kind Regards,
Phil1966 |
|
|