Any plans for Mac updates on the horizon? Still working harder than others while 1.17 is current on macos...
So far I couldn't reproduce the problems that happen with 1.19 out there on our machines here, which would be necessary to track these down and fix it.
I'm working on a CUDA version, which should improve the situation at least for NVidia cards, but this may take a while.
I promoted the 1.18 out of Beta status (for GPUs w. >=1GB) which should solve the work shortage.
DCF should also be more stable with the new plan classes.
The ~6x swings in DCF my fastest host is seeing as DCF swings from being the right value for FGRPB1G tasks to the right value for CPU tasks is only going to be slightly affected by going from 1.18-beta to 1.18-release. When it was dialed in to be correctly predicting 1.18-beta tasks to run in 24min, it was also predicting O1MD1CV tasks to run in 115 minutes while new GPU tasks were predicted as 20m. After I suspended all my old GPU tasks to get it running the new ones they completed in 21-24 minutes which was enough to predict the DCF controlled ETA for the CPU tasks to 125 minutes. In reality the host still needs a bit more than 12 hours to finish those tasks; so the wild gyrations in DCF and massive oversupply of CPU tasks that it periodically results in are only going to be minimally affected.
I'm working on a CUDA version, which should improve the situation at least for NVidia cards, but this may take a while.
Hi Bernd,
thank you for your efforts - however I am on R9 so I guess I won't benefit. Is there anything I as a MacOS/AMD user can do to help? Would be glad to manually test beta releases, preferably on a small, fixed number of WU so the regular work is unaffected, if this is possible.
Kailee.
PS: I have, since the problems with 1.18 occurred, improved the cooling on my machines just in case the chipset or RAM was the culprit. GPU and CPU temps were already ok before, so unlikely to have caused the problems.
I have cpu usage set at 100% with no other projects running. The WUs say using "1 CPU + 1 GPU" . Does that mean it uses only 1 cpu core or as many free cores it can use?
I have cpu usage set at 100% with no other projects running. The WUs say using "1 CPU + 1 GPU" . Does that mean it uses only 1 cpu core or as many free cores it can use?
Crunching 1 workunit on GPU occupies 1 CPU core. Thus, with 1 GPU-workunit active on a 2 core system, 1 core is left for crunching a CPU-workunit.
I have cpu usage set at 100% with no other projects running. The WUs say using "1 CPU + 1 GPU" . Does that mean it uses only 1 cpu core or as many free cores it can use?
For all BOINC projects, it will inhibit CPU crunching from one core even if the GPU doesn't use the CPU very much. It has no effect on how much CPU is used for GPU tasks, its just a limiter for CPU tasks. For these OpenCL E@H tasks it will use the CPU quite heavily.
For all BOINC projects, it will inhibit CPU crunching from one core even if the GPU doesn't use the CPU very much.
That's true except for projects that are using VirtualBox like Cosmology@home or Atlas@home. Even if one full core is allocated for the GPU, the virtual machine will request all cores, ignoring other projects. It will considerably decrease gpu use.
Another pitfall with such projects is that they are very resources greedy when multicores are used. Even with BOINC is limited to 3/4th of CPU, 1 core is free but CPU can't feed GPU.
As it is jerking like when trying to use your computer with hyperpi working, which is very memory bandpass exigent, I believe Virtualbox is memory band pass or L2 cache band pass limited. But maybe I am wrong and I will be pleased to read another expert explanation. My computer is an i5 4670K @ 4.4 GHz with 16 Go RAM @ 1800 MHz and a HD 7970.
I have cpu usage set at 100% with no other projects running. The WUs say using "1 CPU + 1 GPU" . Does that mean it uses only 1 cpu core or as many free cores it can use?
For all BOINC projects, it will inhibit CPU crunching from one core even if the GPU doesn't use the CPU very much. It has no effect on how much CPU is used for GPU tasks, its just a limiter for CPU tasks. For these OpenCL E@H tasks it will use the CPU quite heavily.
Yes, or the nvidia tasks it seems to be using 1 core 100% most of the time. I'd like it to use more than one core, if it can if I have idle cores. Is there a way to make it say, 2 cpus + 1 gpu ?
I have cpu usage set at 100% with no other projects running. The WUs say using "1 CPU + 1 GPU" . Does that mean it uses only 1 cpu core or as many free cores it can use?
For all BOINC projects, it will inhibit CPU crunching from one core even if the GPU doesn't use the CPU very much. It has no effect on how much CPU is used for GPU tasks, its just a limiter for CPU tasks. For these OpenCL E@H tasks it will use the CPU quite heavily.
Yes, or the nvidia tasks it seems to be using 1 core 100% most of the time. I'd like it to use more than one core, if it can if I have idle cores. Is there a way to make it say, 2 cpus + 1 gpu ?
As mmonnin has pointed out, the "1 CPU + 1 GPU" setting just causes your BOINC client to prevent any CPU task under the control of BOINC from using that core. It has absolutely no effect in forcing the GPU app to make productive use of that available resource. You could easily override the default values (1 + 1) with whatever values you wanted. The mechanism is an app_config.xml file. However "2 + 1" would make no significant difference to the speed of execution of the GPU tasks. It would just make a further reduction in how many CPU tasks could be running concurrently.
The requirement of a full CPU core to 'support' the running GPU task is important for nvidia GPUs. The same default allocation of resources applies to AMD GPUs but (at least for the models I use) the CPU resources used are far less. Most of mine run 2 concurrent GPU tasks using "0.3 CPUs + 0.5 GPUs" as set by app_config.xml. I do this deliberately so that even running 3 GPU tasks concurrently would NOT 'reserve' any CPU cores. I 'reserve' a CPU core in a different manner. In BOINCs computing preferences (processor usage), I set the BOINC usage preference to 50% on a dual core machine or 75% on a quad core.
I do it this way so that BOINC adjusts the CPU task fetching to be more appropriate for the number of cores that will be available for crunching CPU tasks. The "1 CPU + 1 GPU" default or the app_config.xml override mechanisms don't seem allow BOINC to fetch CPU tasks appropriately - at least for the version of BOINC I use (7.2.42). I run Linux and BOINC isn't in my distro's repo. I just use what's available from Berkeley. So, for a quad core machine with an nvidia GPU running 2x, BOINC (7.2.42) would still fetch work for 4 cores even though there would be only 2 cores doing the crunching. Some of the CPU task overfetch problems that people mention is probably due to this. If BOINC 'knows' it is restricted to 50% of the cores through that particular preference setting, it will fetch appropriately. It doesn't seem to know when app_config has reserved some cores.
OpenCL-NVidia and OpenCL-ATI are different plan classes. Currently the CPU usage for NVidia certainly should stay at 100%, but would it help if we reduce that of the ATI one? If so, how much? 50%? 33%?
Kai Leibrandt wrote:Any plans
)
So far I couldn't reproduce the problems that happen with 1.19 out there on our machines here, which would be necessary to track these down and fix it.
I'm working on a CUDA version, which should improve the situation at least for NVidia cards, but this may take a while.
BM
Bernd Machenschalk
)
The ~6x swings in DCF my fastest host is seeing as DCF swings from being the right value for FGRPB1G tasks to the right value for CPU tasks is only going to be slightly affected by going from 1.18-beta to 1.18-release. When it was dialed in to be correctly predicting 1.18-beta tasks to run in 24min, it was also predicting O1MD1CV tasks to run in 115 minutes while new GPU tasks were predicted as 20m. After I suspended all my old GPU tasks to get it running the new ones they completed in 21-24 minutes which was enough to predict the DCF controlled ETA for the CPU tasks to 125 minutes. In reality the host still needs a bit more than 12 hours to finish those tasks; so the wild gyrations in DCF and massive oversupply of CPU tasks that it periodically results in are only going to be minimally affected.
Bernd Machenschalk wrote:I'm
)
Hi Bernd,
thank you for your efforts - however I am on R9 so I guess I won't benefit. Is there anything I as a MacOS/AMD user can do to help? Would be glad to manually test beta releases, preferably on a small, fixed number of WU so the regular work is unaffected, if this is possible.
Kailee.
PS: I have, since the problems with 1.18 occurred, improved the cooling on my machines just in case the chipset or RAM was the culprit. GPU and CPU temps were already ok before, so unlikely to have caused the problems.
I have cpu usage set at 100%
)
I have cpu usage set at 100% with no other projects running. The WUs say using "1 CPU + 1 GPU" . Does that mean it uses only 1 cpu core or as many free cores it can use?
Vasishk-Taneya wrote:I have
)
Crunching 1 workunit on GPU occupies 1 CPU core. Thus, with 1 GPU-workunit active on a 2 core system, 1 core is left for crunching a CPU-workunit.
Vasishk-Taneya wrote:I have
)
For all BOINC projects, it will inhibit CPU crunching from one core even if the GPU doesn't use the CPU very much. It has no effect on how much CPU is used for GPU tasks, its just a limiter for CPU tasks. For these OpenCL E@H tasks it will use the CPU quite heavily.
mmonnin wrote:Vasishk-Taneya
)
That's true except for projects that are using VirtualBox like Cosmology@home or Atlas@home. Even if one full core is allocated for the GPU, the virtual machine will request all cores, ignoring other projects. It will considerably decrease gpu use.
Another pitfall with such projects is that they are very resources greedy when multicores are used. Even with BOINC is limited to 3/4th of CPU, 1 core is free but CPU can't feed GPU.
As it is jerking like when trying to use your computer with hyperpi working, which is very memory bandpass exigent, I believe Virtualbox is memory band pass or L2 cache band pass limited. But maybe I am wrong and I will be pleased to read another expert explanation. My computer is an i5 4670K @ 4.4 GHz with 16 Go RAM @ 1800 MHz and a HD 7970.
mmonnin wrote:Vasishk-Taneya
)
Yes, or the nvidia tasks it seems to be using 1 core 100% most of the time. I'd like it to use more than one core, if it can if I have idle cores. Is there a way to make it say, 2 cpus + 1 gpu ?
Vasishk-Taneya wrote:mmonnin
)
As mmonnin has pointed out, the "1 CPU + 1 GPU" setting just causes your BOINC client to prevent any CPU task under the control of BOINC from using that core. It has absolutely no effect in forcing the GPU app to make productive use of that available resource. You could easily override the default values (1 + 1) with whatever values you wanted. The mechanism is an app_config.xml file. However "2 + 1" would make no significant difference to the speed of execution of the GPU tasks. It would just make a further reduction in how many CPU tasks could be running concurrently.
The requirement of a full CPU core to 'support' the running GPU task is important for nvidia GPUs. The same default allocation of resources applies to AMD GPUs but (at least for the models I use) the CPU resources used are far less. Most of mine run 2 concurrent GPU tasks using "0.3 CPUs + 0.5 GPUs" as set by app_config.xml. I do this deliberately so that even running 3 GPU tasks concurrently would NOT 'reserve' any CPU cores. I 'reserve' a CPU core in a different manner. In BOINCs computing preferences (processor usage), I set the BOINC usage preference to 50% on a dual core machine or 75% on a quad core.
I do it this way so that BOINC adjusts the CPU task fetching to be more appropriate for the number of cores that will be available for crunching CPU tasks. The "1 CPU + 1 GPU" default or the app_config.xml override mechanisms don't seem allow BOINC to fetch CPU tasks appropriately - at least for the version of BOINC I use (7.2.42). I run Linux and BOINC isn't in my distro's repo. I just use what's available from Berkeley. So, for a quad core machine with an nvidia GPU running 2x, BOINC (7.2.42) would still fetch work for 4 cores even though there would be only 2 cores doing the crunching. Some of the CPU task overfetch problems that people mention is probably due to this. If BOINC 'knows' it is restricted to 50% of the cores through that particular preference setting, it will fetch appropriately. It doesn't seem to know when app_config has reserved some cores.
Cheers,
Gary.
OpenCL-NVidia and OpenCL-ATI
)
OpenCL-NVidia and OpenCL-ATI are different plan classes. Currently the CPU usage for NVidia certainly should stay at 100%, but would it help if we reduce that of the ATI one? If so, how much? 50%? 33%?
BM