The science app will use however much CPU support it needs. There are no settings in BOINC that will change that. The role of BOINC is to call the science app to run, but has no control over what the app does after that.
the cpu_usage setting only informs BOINC of how much CPU is being used by the app, for the client’s own bookkeeping of available resources. If you set this to 1.0, it will reserve a whole thread for the GPU task while it’s running, and will take that thread away from the pool of available threads to run other tasks. If that GPU task is suspended, the CPU thread will be used for something else, up to your total CPU usage settings in the compute preferences.
What I was expecting to hear. Thanks.
So, if I run 8 tasks total in the GPU and set cpu_usage to 0.125, will that still reserve only a single thread? Would things change if I am running 2 apps, 4 tasks each? Depending on what impact that had on completion time, I could live with that -- one thread per task I cannot. I could probably still live with giving the GPU tasks 2 threads for their use.
I would recommend against doing that, unless you’re sure that the real CPU use from the GPU app is low enough to not cause problems. Some apps need a whole CPU thread for support, and some can get away with less.
For example, if your app needs a whole CPU thread, but you tell BOINC that it’s only using 0.125, then BOINC will think there are more available resources than there really is. This will lead to running more processes than you have CPU threads and one or likely both CPU apps and GPU apps will slow down more than they would otherwise be without an overcommitted CPU.
my advice is to run the app, get a feel for how much CPU support it actually needs, then tune your settings accordingly.
When do you expect to start? Your system profile still doesn't list a GPU.
A Proud member of the O.F.A. (Old Farts Association). Be well, do good work, and keep in touch.® (Garrison Keillor) I want some more patience. RIGHT NOW!
For example, if your app needs a whole CPU thread, but you tell BOINC that it’s only using 0.125, then BOINC will think there are more available resources than there really is. This will lead to running more processes than you have CPU threads and one or likely both CPU apps and GPU apps will slow down more than they would otherwise be without an overcommitted CPU.
my advice is to run the app, get a feel for how much CPU support it actually needs, then tune your settings accordingly.
I'm not sure if that is the case. I was thinking quite a bit about the meaning and ramifications of what you were saying. I was basically getting nowhere, so I decided to take a deep dive into the land of Google. I finally found BOINC: A Platform for Volunteer Computing by David Anderson of the BOINC Project, dated Dec 2018, on page 20:
"Each job J has a fixed resource usage: the number (possibly fractional) of instances of each processing
resource that it uses while executing. For CPUs, fractional resource usage refers to time: 0.5 means that
J has 1 thread that runs half the time. For GPUs, fractional usage typically refers to core usage: 0.5
means that J uses half the GPU’s cores. In either case, throughput is maximized by running 2 such jobs
at once."
Taken at face value, this means that one CPU will be dedicated to every task, and also that a job with 0.5 CPU usage will leave one CPU thread sitting idle half the time it is running -- which would be a total waste of that computing power. Multiply this by the 8 GPU tasks I would like to be running concurrently, and that would have 8 threads sitting idle half the time -- on a system that can reasonably handle only 20 threads devoted to BOINC. That is the equivalent of 4 threads sitting idle 100% of the time, that is, 25% of my processor's computing power. If those 8 tasks actually require a CPU only 25% of the time, then 8 threads would be sitting idle 75% of the time, ie. 30% of the capacity of the entire CPU. I have lots to say about how I think BOINC should be designed, if anyone is at all interested.
(At this point, I have to ask myself, just what is the point of having <cpu_usage> in the app_config file at all? Just give the GPU task a thread, and let it do with it what it will -- unless, of course, the task virtual machine has a way to signal to BOINC when it needs the CPU, and when it is done with it, which does not seem to be the case.)
Certainly, to regain that lost productivity, a GPU task need only be as productive[1] as a CPU-only task. The question I seem now to be facing is whether or not any gain due to GPU-task productivity is sufficient to justify my spending $500[2] to get a decent second GPU to install in this system.
[1] Here, productivity is defined, not as credit awarded, but actual meaningful scientific work done. On LHC and Rosetta (the other 2 projects where I participate), credit is awarded on the basis of the "official" BOINC method, whereas here on Einstein, each task of a particular type is awarded the same credit, regardless of actual runtime credit for FGRP5 is 693 per task, while for BRP4G it is 500. O3AS and BRP7 hand out 10,000 and 3,333, respectively. After poking around on this site for awhile, it seems those 2 average 14 to 15 thousand credits per hour. My FGRP5 tasks are generating around 175-200 per hour. On Einstein and LHC, the credits are all coming out around 65 per hour.
So the actual credit awarded for completing a single task turns out to be meaningless, in which case the entire credit system is meaningless. The only important thing is the actual amount of work done -- real scientific computing that can be put to good use.
[2] Cost is not the only limiting factor in my choice of a GPU. I am also limited by maximum board length -- this is a rather old case which was not designed for GPU cards that are several miles ( ;) ) long.
When do you expect to start? Your system profile still doesn't list a GPU.
It's on hold right now; I have some car repairs to take care of first, and I need a new eyeglasses prescription. And then there is the issue of how much productivity gain can I get? Will it be enough to justify the cost of a dedicated GPU?
That is the case. I have extensive experience with BOINC and what all the settings actually do from empirical data. Your interpretation of DA's words in a paper to showcase BOINC (it doesn't go too far into the weeds about what actually happens in the code) isn't correct. and frankly, I'm not sure what DA is even talking about in terms of a GPU at 0.5 using "half the cores" since not a single app works this way and BOINC has no way to enforce this. DA is often wrong. I think he just used a poor choice of words here that's making it be easily misinterpreted by the reader.
the <gpu_versions><cpu_usage> setting tells the BOINC client how much CPU is used by the GPU app. nothing else. note, I am only talking about the cpu_usage setting as it pertains to GPU applications, since that's what you've been asking about.
you won't have any threads sitting idle unless you configure it to do so. my suggestion to avoid this is to never reduce the CPU time setting (in compute preferences) from 100%. and if you set CPU use % to something like 95+% it will use all except 1 thread. if you set it to 100% it will use all threads. resource share between projects is a whole other can of worms that can impact what tasks get run from what projects.
where it delves out resources is in the jobs in the queue that are waiting to run. Here BOINC will use the bookeeping of how many resources are available, and how many resources are needed, both CPU and GPU, by each task. if you lie to BOINC about how many resources are needed, then it will act on that lie.
hypothetically, if you were to have a 20-thread CPU, and 8x GPUs and 100% CPU use/time setting, assuming that the app ACTUALLY needs a full core support (like it does for O3AS):
with 1x task per GPU, cpu_usage for the GPU app set to 1.0, BOINC would allocate 8x CPU threads for the GPU tasks, leaving 12 available to run CPU tasks, in whatever configurations you've set. 12x 1-thread tasks, 3x 4-thread tasks, whatever.
with 1x task per GPU, cpu_usage for the GPU app set to 0.5, BOINC would allocate 4x CPU threads for the GPU tasks, leaving 16 available threads for the CPU tasks. so 16 threads would be allowed to run CPU tasks, but you would be overcommited because those 8x GPU tasks are still trying to also use a full core. the CPU would be trying to juggle processes trying to use 24 threads on a 20-thread system. the scheduler will timeslice based on the process priority (i think GPU tasks are generally given higher priority in BOINC). runtimes of the CPU tasks is likely to suffer, and probably the GPU tasks too to some extent, especially in the case of O3AS.
the "point" of the <cpu_usage> flag here is a matter of configuration. because while some (maybe even many) apps will use a full CPU thread for GPU support, it's not universally the case. in the case of the BRP7 CUDA app for example, CPU use is actually incredibly low for GPU support. if you watch it running you'll see it using like less than 10% of a single thread. so you can dial that back in BOINC and allow some more CPU tasks to run with no detriment.
It's on hold right now; I have some car repairs to take care of first, and I need a new eyeglasses prescription. And then there is the issue of how much productivity gain can I get? Will it be enough to justify the cost of a dedicated GPU?
the cost justification will be subjective, and really only you can answer that. but objectively, for Einstein, GPUs are are massively more productive, from a points per day (ppd) standpoint. Hard to directly compare here since Einstein does not run the same subprojects on CPU and GPU, and the points scales are not the same or event really comparable. (same with other projects, you can't compare the points directly since not all projects award points in the same way)
your current CPU is capable of maybe <100,000 ppd. a single GPU can easily be 10-50x that much, depending what you choose and what subproject you're interested in running.
I would figure out what GPU you're interested in that's in your price range, then look through the leaderboards for folks running that same GPU to get an idea of it's projected performance.
For Linux systems, maybe the equivalent can be said for Windows system, Boinc will run all cpu tasks at NICE level = 19.
For gpu tasks, Boinc will all gpu tasks at NICE level =10.
There is an override setting for app_config that is supposedly capable of bumping gpu priority higher for specific brand cards but I have never seen it work correctly and it does nothing in fact.
NICE level higher number values mean lower priority with range from -20 to +20 with negative values being the highest priorities.
It's on hold right now; I have some car repairs to take care of first, and I need a new eyeglasses prescription. And then there is the issue of how much productivity gain can I get? Will it be enough to justify the cost of a dedicated GPU?
the cost justification will be subjective, and really only you can answer that. but objectively, for Einstein, GPUs are are massively more productive, from a points per day (ppd) standpoint. Hard to directly compare here since Einstein does not run the same subprojects on CPU and GPU, and the points scales are not the same or event really comparable. (same with other projects, you can't compare the points directly since not all projects award points in the same way)
True. I have, in fact, already selected the GPU I would be getting. Not only does it come well within my anticipated budget, but it also falls well within the card size limitation imposed by my system layout -- it isn't a huge case, and I tend to let cables fall wherever they will, which puts about a 9" limit on card size.
By "points", are you referring to credits awarded, or something else? If it's credits, those are of little to no concern to me -- I am simply interested in increasing the number of tasks my system can get done in a single day.
As for all those other constraints on my pocketbook, I am getting close on those, so it might not be all that long before I can go ahead with the GPU purchase -- wish me luck :)
Quote:
your current CPU is capable of maybe <100,000 ppd. a single GPU can easily be 10-50x that much, depending what you choose and what subproject you're interested in running.
I would figure out what GPU you're interested in that's in your price range, then look through the leaderboards for folks running that same GPU to get an idea of it's projected performance.
I'm running LHC, Rosetta and Einstein, with no intention of adding any others. Of those, only Einstein offers GPU tasks, and of those, I have decided I am interested in O3AS and MeerKat -- the former because I am a gravitation theorist and the latter because I read the code for that one is highly optimized :)
So I read what you say as meaning the GPU tasks are at least 10 times as productive as CPU-only tasks, give or take a fiddle factor for things like coding efficiency, total work which can be done, etc. If so, that alone probably will be enough for me to justify getting that GPU.
As for checking leaderboards, how would I go about locating those? I haven't found any; there don't seem to be any obvious links to such a thing.
PS, must be nice to have all those 64-core Epyc processors to play with :D
For Linux systems, maybe the equivalent can be said for Windows system, Boinc will run all cpu tasks at NICE level = 19.
For gpu tasks, Boinc will all gpu tasks at NICE level =10.
There is an override setting for app_config that is supposedly capable of bumping gpu priority higher for specific brand cards but I have never seen it work correctly and it does nothing in fact.
NICE level higher number values mean lower priority with range from -20 to +20 with negative values being the highest priorities.
I don't see anything in the current Boinc documentation for such an app_config setting. If it actually does nothing, perhaps they simply got rid of it?
hadron wrote: Ian&Steve C.
)
I would recommend against doing that, unless you’re sure that the real CPU use from the GPU app is low enough to not cause problems. Some apps need a whole CPU thread for support, and some can get away with less.
For example, if your app needs a whole CPU thread, but you tell BOINC that it’s only using 0.125, then BOINC will think there are more available resources than there really is. This will lead to running more processes than you have CPU threads and one or likely both CPU apps and GPU apps will slow down more than they would otherwise be without an overcommitted CPU.
my advice is to run the app, get a feel for how much CPU support it actually needs, then tune your settings accordingly.
_________________________________________________________________________
hadron wrote: Keith Myers
)
+1
Hadron, When do you expect
)
Hadron,
When do you expect to start? Your system profile still doesn't list a GPU.
A Proud member of the O.F.A. (Old Farts Association). Be well, do good work, and keep in touch.® (Garrison Keillor) I want some more patience. RIGHT NOW!
Ian&Steve C. wrote:For
)
I'm not sure if that is the case. I was thinking quite a bit about the meaning and ramifications of what you were saying. I was basically getting nowhere, so I decided to take a deep dive into the land of Google. I finally found BOINC: A Platform for Volunteer Computing by David Anderson of the BOINC Project, dated Dec 2018, on page 20:
Taken at face value, this means that one CPU will be dedicated to every task, and also that a job with 0.5 CPU usage will leave one CPU thread sitting idle half the time it is running -- which would be a total waste of that computing power. Multiply this by the 8 GPU tasks I would like to be running concurrently, and that would have 8 threads sitting idle half the time -- on a system that can reasonably handle only 20 threads devoted to BOINC. That is the equivalent of 4 threads sitting idle 100% of the time, that is, 25% of my processor's computing power. If those 8 tasks actually require a CPU only 25% of the time, then 8 threads would be sitting idle 75% of the time, ie. 30% of the capacity of the entire CPU. I have lots to say about how I think BOINC should be designed, if anyone is at all interested.
(At this point, I have to ask myself, just what is the point of having <cpu_usage> in the app_config file at all? Just give the GPU task a thread, and let it do with it what it will -- unless, of course, the task virtual machine has a way to signal to BOINC when it needs the CPU, and when it is done with it, which does not seem to be the case.)
Certainly, to regain that lost productivity, a GPU task need only be as productive[1] as a CPU-only task. The question I seem now to be facing is whether or not any gain due to GPU-task productivity is sufficient to justify my spending $500[2] to get a decent second GPU to install in this system.
[1] Here, productivity is defined, not as credit awarded, but actual meaningful scientific work done. On LHC and Rosetta (the other 2 projects where I participate), credit is awarded on the basis of the "official" BOINC method, whereas here on Einstein, each task of a particular type is awarded the same credit, regardless of actual runtime credit for FGRP5 is 693 per task, while for BRP4G it is 500. O3AS and BRP7 hand out 10,000 and 3,333, respectively. After poking around on this site for awhile, it seems those 2 average 14 to 15 thousand credits per hour. My FGRP5 tasks are generating around 175-200 per hour. On Einstein and LHC, the credits are all coming out around 65 per hour.
So the actual credit awarded for completing a single task turns out to be meaningless, in which case the entire credit system is meaningless. The only important thing is the actual amount of work done -- real scientific computing that can be put to good use.
[2] Cost is not the only limiting factor in my choice of a GPU. I am also limited by maximum board length -- this is a rather old case which was not designed for GPU cards that are several miles ( ;) ) long.
Tom M wrote: Hadron, When
)
It's on hold right now; I have some car repairs to take care of first, and I need a new eyeglasses prescription. And then there is the issue of how much productivity gain can I get? Will it be enough to justify the cost of a dedicated GPU?
hadron wrote:I'm not sure
)
That is the case. I have extensive experience with BOINC and what all the settings actually do from empirical data. Your interpretation of DA's words in a paper to showcase BOINC (it doesn't go too far into the weeds about what actually happens in the code) isn't correct. and frankly, I'm not sure what DA is even talking about in terms of a GPU at 0.5 using "half the cores" since not a single app works this way and BOINC has no way to enforce this. DA is often wrong. I think he just used a poor choice of words here that's making it be easily misinterpreted by the reader.
the <gpu_versions><cpu_usage> setting tells the BOINC client how much CPU is used by the GPU app. nothing else. note, I am only talking about the cpu_usage setting as it pertains to GPU applications, since that's what you've been asking about.
you won't have any threads sitting idle unless you configure it to do so. my suggestion to avoid this is to never reduce the CPU time setting (in compute preferences) from 100%. and if you set CPU use % to something like 95+% it will use all except 1 thread. if you set it to 100% it will use all threads. resource share between projects is a whole other can of worms that can impact what tasks get run from what projects.
where it delves out resources is in the jobs in the queue that are waiting to run. Here BOINC will use the bookeeping of how many resources are available, and how many resources are needed, both CPU and GPU, by each task. if you lie to BOINC about how many resources are needed, then it will act on that lie.
hypothetically, if you were to have a 20-thread CPU, and 8x GPUs and 100% CPU use/time setting, assuming that the app ACTUALLY needs a full core support (like it does for O3AS):
with 1x task per GPU, cpu_usage for the GPU app set to 1.0, BOINC would allocate 8x CPU threads for the GPU tasks, leaving 12 available to run CPU tasks, in whatever configurations you've set. 12x 1-thread tasks, 3x 4-thread tasks, whatever.
with 1x task per GPU, cpu_usage for the GPU app set to 0.5, BOINC would allocate 4x CPU threads for the GPU tasks, leaving 16 available threads for the CPU tasks. so 16 threads would be allowed to run CPU tasks, but you would be overcommited because those 8x GPU tasks are still trying to also use a full core. the CPU would be trying to juggle processes trying to use 24 threads on a 20-thread system. the scheduler will timeslice based on the process priority (i think GPU tasks are generally given higher priority in BOINC). runtimes of the CPU tasks is likely to suffer, and probably the GPU tasks too to some extent, especially in the case of O3AS.
the "point" of the <cpu_usage> flag here is a matter of configuration. because while some (maybe even many) apps will use a full CPU thread for GPU support, it's not universally the case. in the case of the BRP7 CUDA app for example, CPU use is actually incredibly low for GPU support. if you watch it running you'll see it using like less than 10% of a single thread. so you can dial that back in BOINC and allow some more CPU tasks to run with no detriment.
_________________________________________________________________________
hadron wrote: It's on hold
)
the cost justification will be subjective, and really only you can answer that. but objectively, for Einstein, GPUs are are massively more productive, from a points per day (ppd) standpoint. Hard to directly compare here since Einstein does not run the same subprojects on CPU and GPU, and the points scales are not the same or event really comparable. (same with other projects, you can't compare the points directly since not all projects award points in the same way)
your current CPU is capable of maybe <100,000 ppd. a single GPU can easily be 10-50x that much, depending what you choose and what subproject you're interested in running.
I would figure out what GPU you're interested in that's in your price range, then look through the leaderboards for folks running that same GPU to get an idea of it's projected performance.
_________________________________________________________________________
For Linux systems, maybe the
)
For Linux systems, maybe the equivalent can be said for Windows system, Boinc will run all cpu tasks at NICE level = 19.
For gpu tasks, Boinc will all gpu tasks at NICE level =10.
There is an override setting for app_config that is supposedly capable of bumping gpu priority higher for specific brand cards but I have never seen it work correctly and it does nothing in fact.
NICE level higher number values mean lower priority with range from -20 to +20 with negative values being the highest priorities.
Ian&Steve C. wrote:hadron
)
True. I have, in fact, already selected the GPU I would be getting. Not only does it come well within my anticipated budget, but it also falls well within the card size limitation imposed by my system layout -- it isn't a huge case, and I tend to let cables fall wherever they will, which puts about a 9" limit on card size.
By "points", are you referring to credits awarded, or something else? If it's credits, those are of little to no concern to me -- I am simply interested in increasing the number of tasks my system can get done in a single day.
As for all those other constraints on my pocketbook, I am getting close on those, so it might not be all that long before I can go ahead with the GPU purchase -- wish me luck :)
I'm running LHC, Rosetta and Einstein, with no intention of adding any others. Of those, only Einstein offers GPU tasks, and of those, I have decided I am interested in O3AS and MeerKat -- the former because I am a gravitation theorist and the latter because I read the code for that one is highly optimized :)
So I read what you say as meaning the GPU tasks are at least 10 times as productive as CPU-only tasks, give or take a fiddle factor for things like coding efficiency, total work which can be done, etc. If so, that alone probably will be enough for me to justify getting that GPU.
As for checking leaderboards, how would I go about locating those? I haven't found any; there don't seem to be any obvious links to such a thing.
PS, must be nice to have all those 64-core Epyc processors to play with :D
Keith Myers wrote: For Linux
)
I don't see anything in the current Boinc documentation for such an app_config setting. If it actually does nothing, perhaps they simply got rid of it?