Gary i played around with your idea on my GTX1060 fed by an I5 running 2 @ a time.
using 100% of CPU gave ~ 35% load on the GPU
Using 75% of CPU gave ~ 45% load on the GPU
Using 50% of CPU gives well over 50% load on the GPU
These devils want a lot of CPU to feed the GPU.
Edit, as an added bonus when I use 100% of the CPU it is so slowly loaded that it on;y needs to run @ 1550MHz to keep up vs 1993MHz on the other 2 settings
I'm not sure I understand exactly what you're doing.
Betreger wrote:
Gary i played around with your idea on my GTX1060 fed by an I5 running 2 @ a time.
I assume this means that the GPU was running two concurrent tasks whilst being supported by a quad core i5. You don't mention the number of CPU tasks running. I assume you are running what the settings allow? The references to "100% of CPU, 75% of CPU", etc., refer to the % of cores BOINC is allowed to use for CPU tasks. Off the top of my head, I'll suggest a table below showing the assumed running tasks for each setting you mention, based on the above. Please correct me if I'm misinterpreting what you've been doing.
I'll assume you are not using an app_config.xml file but rather you have set the utilization factor to 0.5 to achieve the two concurrent GPU tasks. This would cause the current default 1.8 CPUs (ie. just 1 core) to be 'reserved' by BOINC for GPU support duties.
Ideally, there should be figures measured for CPU crunching only with the discrete GPU removed and using the on board GPU only for the display. Leaving the discrete GPU installed would add extra power draw that's not attributable to the CPU tasks only. I've added an initial line to the table for that purpose.
The GPU load isn't really useful for determining the most efficient setup. What needs to be carefully measured are the 'xxxx' missing values Also, the whole table needs to be repeated for different numbers of concurrent GPU tasks, possibly as high as 4 or 5.
I'm not suggesting you must do this. It's just the sort of information I hope to measure when there is a Linux app. Also, my intention was to look at how much more efficient it might be to crunch this work only on the GPU. That's why I added a line for 25% of BOINC cores allowed.
Gary running @ 50% GPU utilization it ends up running 1 task on the CPU, why I don't know.
Elapsed time is my main concern and as far as the power usage goes the heat is almost always welcome since my home heating system burns electricity anyway.
As an aside these things pay very poorly but I don't care, I am much more interested in gravity waves than pulsars.
Gary running @ 50% GPU utilization it ends up running 1 task on the CPU, why I don't know.
You didn't comment about whether or not my assumptions were correct, so I'll assume they were. When you said you had 50% GPU load, you were allowing BOINC to use 50% of the cores - ie. 2 cores. By running 2 GPU tasks, BOINC is required to budget 2x0.9=1.8 cores for GPU support. Fractional numbers like that are always rounded down (and fractional cores remaining are rounded up) so the 2-1.8=0.2 cores left, allows BOINC to run a CPU task.
If you don't want that CPU task to run, either use app_config.xml to set both parameters to suitable values, or disable CPU crunching completely, or easier still, just set the GPU utilization factor to 0.33 whilst leaving the % cores at 50%. From the two allowed cores BOINC will subtract 3x0.9=2.7. You have a deficit of 0.7 cores so BOINC will prevent any CPU tasks from running. You will be running 3 GPU tasks and I suspect you will get a greater throughput and hence a warmer house :-).
I don't know if you run other projects on this machine or not. The above discussion assumes just Einstein. If you run other GPU searches, the picture won't be as simple as I've outlined above. Also, if you have CPU tasks in your cache, they will be prevented from running until they get to deadline territory. So, to not run them, you would need to turn off receiving them in the future and abort whatever tasks are still in the cache.
Betreger wrote:
Elapsed time is my main concern and as far as the power usage goes the heat is almost always welcome since my home heating system burns electricity anyway.
If you find settings that maximise your output per unit of time, you'll pretty much be guaranteed to have the maximum heating effect :-). What you're really trying to do is get rather more output for not as much more power consumption.
Betreger wrote:
As an aside these things pay very poorly ....
I don't believe you're taking into account the proven fact that a GW credit buys at least 1000x times more cups of coffee than an FGRP credit does :-).
They claim they need (.9 cpu + 1 amd gpu). The problem comes in that since they are not asking for a whole core, they were not getting enough cpu power to run properly..
If you tell BOINC that an app (version) uses a full core, it will 'nice' the process (reduce process priority), which means that the effective usage is determined by the load of the rest of the system and might well be 10% or less. We don't give it a full core to avoid this. If you use your system exclusively to run BOINC, indeed it's better to set aside one core for the GPU App.
BERND, i do not see any difference in the process priority on practice. At least on windows platform BOINC always assign "below normal: 6" for process priority of GPU apps regardless of how much of CPU core it request from BOINC.
I am not sure about internal threads priority in the app (but AFAIK it depends on app devs decisions, not BOINC) but default process priorities are same: idle (4) for CPU apps and below normal (6) for GPU apps.
Also i think there is a possibility to control app process priority directly. I dont know how to implement it, but on some projects (MW for example) GPU apps run at normal (8) priority. But regardless of "reserved" CPU fraction too. I run them at "0.25 CPU + 0.25 GPU" (4 in parallel) and they always get "normal priority" at start. While E@H GPU apps always get "below normal".
P.S.
All my GW WUs are validating fine so far: 19 valid, few dozen are still pending, zero errors and invalids. Only one "stuck" WU which i have aborted manually.
Max, have you looked at Process Lasso? You can raise the priority of the work units in it to normal, high and real time. I use it on my MS machine. I moved the priority to High and assigned only physical cores to the work units.
Yeah, i know about such utilities. But i don't use them as there is a built in "native" BOINC option to "tune" this:
Via option section of cc_config.xml
<process_priority>N</process_priority>, <process_priority_special>N</process_priority_special>
The OS process priority at which tasks are run. Values are 0 (lowest priority, the default), 1 (below normal), 2 (normal), 3 (above normal), 4 (high) and 5 (real-time - not recommended). 'special' process priority is used for coprocessor (GPU) applications, wrapper applications, and non-compute-intensive applications, 'process priority' for all others. The two options can be used independently.
But you don't get a point: there are many possibilities to control process priority from the user side if a particular user pay attention to it and know how to tune it. I.e. for some geeks only.
We spoke about default behavior for ALL users which can be set from the project side.
FWIW I'm currently testing some optimization to the CPU app (version 0.04 .. 0.06 and possibly more) that speeds up an O1OD1 task by about 20% by using a lookup table. The question is basically how large does this need to be to give enough precision to "validate".
slow to validate, 71 pending
)
slow to validate, 71 pending 3 valid
Gary i played around with
)
Gary i played around with your idea on my GTX1060 fed by an I5 running 2 @ a time.
using 100% of CPU gave ~ 35% load on the GPU
Using 75% of CPU gave ~ 45% load on the GPU
Using 50% of CPU gives well over 50% load on the GPU
These devils want a lot of CPU to feed the GPU.
Edit, as an added bonus when I use 100% of the CPU it is so slowly loaded that it on;y needs to run @ 1550MHz to keep up vs 1993MHz on the other 2 settings
I'm not sure I understand
)
I'm not sure I understand exactly what you're doing.
I assume this means that the GPU was running two concurrent tasks whilst being supported by a quad core i5. You don't mention the number of CPU tasks running. I assume you are running what the settings allow? The references to "100% of CPU, 75% of CPU", etc., refer to the % of cores BOINC is allowed to use for CPU tasks. Off the top of my head, I'll suggest a table below showing the assumed running tasks for each setting you mention, based on the above. Please correct me if I'm misinterpreting what you've been doing.
I'll assume you are not using an app_config.xml file but rather you have set the utilization factor to 0.5 to achieve the two concurrent GPU tasks. This would cause the current default 1.8 CPUs (ie. just 1 core) to be 'reserved' by BOINC for GPU support duties.
Ideally, there should be figures measured for CPU crunching only with the discrete GPU removed and using the on board GPU only for the display. Leaving the discrete GPU installed would add extra power draw that's not attributable to the CPU tasks only. I've added an initial line to the table for that purpose.
The GPU load isn't really useful for determining the most efficient setup. What needs to be carefully measured are the 'xxxx' missing values Also, the whole table needs to be repeated for different numbers of concurrent GPU tasks, possibly as high as 4 or 5.
I'm not suggesting you must do this. It's just the sort of information I hope to measure when there is a Linux app. Also, my intention was to look at how much more efficient it might be to crunch this work only on the GPU. That's why I added a line for 25% of BOINC cores allowed.
Cheers,
Gary.
Gary running @ 50% GPU
)
Gary running @ 50% GPU utilization it ends up running 1 task on the CPU, why I don't know.
Elapsed time is my main concern and as far as the power usage goes the heat is almost always welcome since my home heating system burns electricity anyway.
As an aside these things pay very poorly but I don't care, I am much more interested in gravity waves than pulsars.
Betreger wrote:Gary running @
)
You didn't comment about whether or not my assumptions were correct, so I'll assume they were. When you said you had 50% GPU load, you were allowing BOINC to use 50% of the cores - ie. 2 cores. By running 2 GPU tasks, BOINC is required to budget 2x0.9=1.8 cores for GPU support. Fractional numbers like that are always rounded down (and fractional cores remaining are rounded up) so the 2-1.8=0.2 cores left, allows BOINC to run a CPU task.
If you don't want that CPU task to run, either use app_config.xml to set both parameters to suitable values, or disable CPU crunching completely, or easier still, just set the GPU utilization factor to 0.33 whilst leaving the % cores at 50%. From the two allowed cores BOINC will subtract 3x0.9=2.7. You have a deficit of 0.7 cores so BOINC will prevent any CPU tasks from running. You will be running 3 GPU tasks and I suspect you will get a greater throughput and hence a warmer house :-).
I don't know if you run other projects on this machine or not. The above discussion assumes just Einstein. If you run other GPU searches, the picture won't be as simple as I've outlined above. Also, if you have CPU tasks in your cache, they will be prevented from running until they get to deadline territory. So, to not run them, you would need to turn off receiving them in the future and abort whatever tasks are still in the cache.
If you find settings that maximise your output per unit of time, you'll pretty much be guaranteed to have the maximum heating effect :-). What you're really trying to do is get rather more output for not as much more power consumption.
I don't believe you're taking into account the proven fact that a GW credit buys at least 1000x times more cups of coffee than an FGRP credit does :-).
Cheers,
Gary.
waffleironhead wrote:They
)
If you tell BOINC that an app (version) uses a full core, it will 'nice' the process (reduce process priority), which means that the effective usage is determined by the load of the rest of the system and might well be 10% or less. We don't give it a full core to avoid this. If you use your system exclusively to run BOINC, indeed it's better to set aside one core for the GPU App.
BM
BERND, i do not see any
)
BERND, i do not see any difference in the process priority on practice. At least on windows platform BOINC always assign "below normal: 6" for process priority of GPU apps regardless of how much of CPU core it request from BOINC.
I am not sure about internal threads priority in the app (but AFAIK it depends on app devs decisions, not BOINC) but default process priorities are same: idle (4) for CPU apps and below normal (6) for GPU apps.
Also i think there is a possibility to control app process priority directly. I dont know how to implement it, but on some projects (MW for example) GPU apps run at normal (8) priority. But regardless of "reserved" CPU fraction too. I run them at "0.25 CPU + 0.25 GPU" (4 in parallel) and they always get "normal priority" at start. While E@H GPU apps always get "below normal".
P.S.
All my GW WUs are validating fine so far: 19 valid, few dozen are still pending, zero errors and invalids. Only one "stuck" WU which i have aborted manually.
Max, have you looked at
)
Max, have you looked at Process Lasso? You can raise the priority of the work units in it to normal, high and real time. I use it on my MS machine. I moved the priority to High and assigned only physical cores to the work units.
Yeah, i know about such
)
Yeah, i know about such utilities. But i don't use them as there is a built in "native" BOINC option to "tune" this:
Via option section of cc_config.xml
But you don't get a point: there are many possibilities to control process priority from the user side if a particular user pay attention to it and know how to tune it. I.e. for some geeks only.
We spoke about default behavior for ALL users which can be set from the project side.
FWIW I'm currently testing
)
FWIW I'm currently testing some optimization to the CPU app (version 0.04 .. 0.06 and possibly more) that speeds up an O1OD1 task by about 20% by using a lookup table. The question is basically how large does this need to be to give enough precision to "validate".
BM