Message boards :
Number crunching :
HIGH CPU USAGE with new 1.02 OpenCL tasks
Message board moderation
Author | Message |
---|---|
Send message Joined: 22 Apr 11 Posts: 64 Credit: 899,273,836 RAC: 7,579 |
Howdy folks. Well, things were running perfectly with 6.12.34 and 7.0.8 BOINC versions using Catalyst 12.1 and Milkyway 0.82... then the 1.02 WU's came along and now the tasks require I free up 2 of 6 cores to run the HD6990. I tried fresh installs of everything using driver sweeper/reboots etc. and nothing seems to help. The 1100T CPU is running 3.72GHz 24/7 glitch free and used to be fine, but now in task manager, running ONLY MilkyWay, it uses 2 full cores... I can only run 4 other CPU tasks now instead of 6... Sigh... is this the way it is supposed to be? Thanks! 8-) |
Send message Joined: 27 Jan 12 Posts: 38 Credit: 18,084,778 RAC: 0 |
FWIW I had issues with 1.02 on all 3 of my 5830s on 3 different machines. I had to switch back to .82 to get things running smoothly again. I'm not currently running M@H so I don't know if the .82 app will still work. If it doesn't then I will not be able to run M@H on my current hardware. |
Send message Joined: 22 Apr 11 Posts: 64 Credit: 899,273,836 RAC: 7,579 |
I don't think I have a choice as to which WU's to run on the GPU... it ran some .82 units... then a mix of .82 and 1.02, then all 1.02... guess it's up to the project... 8-) |
Send message Joined: 30 Jan 09 Posts: 13 Credit: 140,613,318 RAC: 0 |
With an app_info you can choose to get only 0.82 WU |
Send message Joined: 22 Apr 11 Posts: 64 Credit: 899,273,836 RAC: 7,579 |
Hmm, okay. I think OpenCL is the future and would like to see it get optimized a bit better... it's not a real problem per se... just could be better. The 1.02 takes 60 seconds per WU (vs. 56 seconds on .82) and uses one full CPU core/thread per GPU vs. .82 nill CPU usage. (This on my HD6990) One would hope (think) that the problem could be corrected somehow... 8-) |
Send message Joined: 14 Feb 09 Posts: 999 Credit: 74,932,619 RAC: 0 |
It will be fixed when the drivers are fixed. |
Send message Joined: 22 Apr 11 Posts: 64 Credit: 899,273,836 RAC: 7,579 |
Hmmm, thought they were fixed... doesn't run this high CPU usage on other OpenCL projects I've tested... Oh well, maybe depends what code is running... I don't suppose you would care to explain exactly what is causing the problem? Is is a polling problem? Timing problem? Any Idea? 8-) |
Send message Joined: 16 Aug 10 Posts: 15 Credit: 32,160,978 RAC: 0 |
OK I have an AMD 945 CPU, an ATI 4875, and an 780G chipset motherboard, running XP64. I am NOT using current drivers and have had to limit non-Milky tasks running to 2 cores when I enable GPU computing. It appears as if the bus, dk if memory or which bus, is being very heavily used. I have a HD3200 GPU in my chipset which is driving my secondary monitor. As I type this I am getting extremely choppy video response on my secondary monitor, I did not before. One month ago I was running 3 cores on other grid tasks and 1 Milkyway task on GPU and had NO degradation on my secondary monitor. This post is meant to provide information for those working on the code and the new interface. |
Send message Joined: 8 Feb 08 Posts: 261 Credit: 104,050,322 RAC: 0 |
As default, the app is sending chunks to the gpu and wait for the answer right away. Theoretically this is how it is supposed to be without causing high CPU use. In this situation some drivers in general, other drivers depending on combination of GPU and OS aren't playing nice and causing this high CPU use. The app is trying to catch some of those and inserts a sleep time ('initial wait') before calling for the answer from the gpu. This is how the default polling mode of -2 works from my understanding. If the app thinks you should be fine, it switches to polling mode -1 (asking for gpu answer without initial wait); if it thinks you are a case with 'high CPU issue' it switches to polling mode 0 (using the initial wait before asking for gpu answer). If you see high CPU use, you are obviously one of those cases the app doesn't catch and uses mode -1 instead of mode 0. Don't be surprised if you are setting mode 0 by app_info and see your gpu load dropping. That's what I saw on my computer. I needed to set the gpu-wait-factor far down to get the gpu load back up again. Still trying to understand why I had to push it that far down. Seems to be something in the calculation and use of the initial wait time which is not as simple as I thought first. |
Send message Joined: 22 Apr 11 Posts: 64 Credit: 899,273,836 RAC: 7,579 |
Being novice to using the app_info.xml for controlling things, I wonder if there is a place that shows what and how specific items can be changed... For instance, if I use that Crunchers Corner app_info file, is there some way to pass parameters to the app? In any case, I tried a few things and not entirely sure it isn't some other problem... Thanks for the info! 8-) |
Send message Joined: 8 Feb 08 Posts: 261 Credit: 104,050,322 RAC: 0 |
You said you have used the app_info from arkayn's site. Pretty sure in there is a line with the cmdline tag. That's the place to set params to pass them to the app. i.e. <cmdline>--gpu-polling-mode 0</cmdline> forces the app to use an additional sleep before waiting for the answer from the gpu to prevent high CPU issues <cmdline>--gpu-polling-mode 0 --process-priority 1</cmdline> same as above and lowers the priority of the app to 'below normal' --gpu-wait-factor 0.75 this is the default multiplier used to calculate the sleep time if you are using polling 0 |
Send message Joined: 22 Apr 11 Posts: 64 Credit: 899,273,836 RAC: 7,579 |
Thanks! I only downloaded the app_info file, not used it yet. The only other app file I've used was for Moo! Wrapper to force it to use only 1 GPU per task.. I'll give it a try soon... Thanks again! :D |
Send message Joined: 8 May 10 Posts: 576 Credit: 15,979,383 RAC: 0 |
The workaround is enabled if you're using Nvidia drivers newer than 270.xx or AMD drivers that are 11.7 or 11.8. It seems to have come back again for AMD. The problem is they are busy waiting when you use clFinish or clWaitForEvents to wait for the GPU to complete running things. |
Send message Joined: 22 Jan 11 Posts: 375 Credit: 64,657,871 RAC: 0 |
Err, so what is the answer to high CPU useage & GUI lag? Win XP 32bit, Cat 12.1, HD4830, Q6600 @3.2GHz & BOINC 6.12.34 Tried changing fequency in the MW web preferences, had no effect. TIA Team AnandTech - SETI@H, DPAD, F@H, MW@H, A@H, LHC, POGS, R@H, Einstein@H, DHEP, WCG Main rig - Ryzen 5 3600, MSI B450 G.Pro C. AC, RTX 3060Ti 8GB, 32GB DDR4 3200, Win 10 64bit 2nd rig - i7 4930k @4.1 GHz, HD 7870 XT 3GB(DS), 16GB DDR3 1866, Win7 |
Send message Joined: 8 Feb 08 Posts: 261 Credit: 104,050,322 RAC: 0 |
Like Matt said, the problem for high cpu use is the busy-wait from the driver. Force the app to use a sleep/wait by setting polling mode 0 and than play with the wait factor to get gpu usage back up. Higher frequency gives the gpu more chances to redraw the screen; the wait before polling for answer from gpu reduces the cpu usage. Lowering the priority of the app can help too. After setting polling mode 0 start with setting the frequency high enough that the gui lag is gone, than use the wait factor to get the gpu use up close to where the gui lag starts again. |
Send message Joined: 22 Jan 11 Posts: 375 Credit: 64,657,871 RAC: 0 |
What a lot or arsing about! :/ So I put those commands (as per your post on the 18th?) in the commandline in the shortcut for BOINC? Re the wait factor, you didn't say in which direction the numbers affect MW. Thanks :) Team AnandTech - SETI@H, DPAD, F@H, MW@H, A@H, LHC, POGS, R@H, Einstein@H, DHEP, WCG Main rig - Ryzen 5 3600, MSI B450 G.Pro C. AC, RTX 3060Ti 8GB, 32GB DDR4 3200, Win 10 64bit 2nd rig - i7 4930k @4.1 GHz, HD 7870 XT 3GB(DS), 16GB DDR3 1866, Win7 |
Send message Joined: 8 Feb 08 Posts: 261 Credit: 104,050,322 RAC: 0 |
What a lot or arsing about! :/ To work around those driver problems. Yes, sadly. So I put those commands (as per your post on the 18th?) in the commandline in the shortcut for BOINC? You put it into the app_info.xml for MW. My own line for the params look like this: <cmdline>--gpu-target-frequency 60 --gpu-wait-factor 0.20 --gpu-polling-mode 0 --process-priority 1</cmdline> --gpu-target-frequency 60 is the default, if missing the value from your account profile is used. Higher frequency gives more chances for a screen refresh but leads to higher overhead (more data transfers). --gpu-polling-mode 0 switch to use sleep/wait time calculated by app before polling for results from gpu --process-priority 1 is lowering process prio from default 2, I am feeling more comfortable with it at 'below normal' --gpu-wait-factor 0.20 is far down from default 0.75 but gives me high gpu use on my HD5850 with acceptable system response. Sorry, you need to test yourself how far down you have to go with the wait factor for your HD4830. It depends too much on the individual system. The lower you go, the more cpu usage is increasing again. With the default wait factor (0.75) my gpu load was only 70 - 80%, now I am at ~97%. (The next app version is expected to get a better gpu load with the default wait factor.) If you want my app_info.xml to modify it for your needs, you can send me a PM |
Send message Joined: 22 Jan 11 Posts: 375 Credit: 64,657,871 RAC: 0 |
Thanks for your replie & the info :) However I haven't a clue about the app_info & TBH I don't want to waste time finding out how & then experimenting with dozens of different settings to hit the sweet spot. I will just quit MW whenever I'm using my PC. Team AnandTech - SETI@H, DPAD, F@H, MW@H, A@H, LHC, POGS, R@H, Einstein@H, DHEP, WCG Main rig - Ryzen 5 3600, MSI B450 G.Pro C. AC, RTX 3060Ti 8GB, 32GB DDR4 3200, Win 10 64bit 2nd rig - i7 4930k @4.1 GHz, HD 7870 XT 3GB(DS), 16GB DDR3 1866, Win7 |
Send message Joined: 8 May 09 Posts: 3315 Credit: 519,947,628 RAC: 22,118 |
Thanks for your replie & the info :) In version 7.0.20 of Boinc there is an exclude tab section where you can put in a program name and Boinc will not crunch while it is running, pretty cool. BE CAREFUL upgrading though, it is not easy to go back to the regular version and the 7 versions are still Beta. AND some projects do not handle it well, although that could be more a particular version rather than the whole 7 series. |
Send message Joined: 22 Jan 11 Posts: 375 Credit: 64,657,871 RAC: 0 |
Interesting,that could be useful, thx :). Inccidently I went from 7.0.18 back to v6 without problems. Team AnandTech - SETI@H, DPAD, F@H, MW@H, A@H, LHC, POGS, R@H, Einstein@H, DHEP, WCG Main rig - Ryzen 5 3600, MSI B450 G.Pro C. AC, RTX 3060Ti 8GB, 32GB DDR4 3200, Win 10 64bit 2nd rig - i7 4930k @4.1 GHz, HD 7870 XT 3GB(DS), 16GB DDR3 1866, Win7 |
©2024 Astroinformatics Group