Message boards : Frequently Asked Questions (FAQ) : Please set CPU usage to 1 CPU for GPU Acemd tasks.
Author | Message |
---|---|
Hello! | |
ID: 53851 | Rating: 0 | rate: / Reply Quote | |
I do it in my app_config.xml file: <app_config> <app> <name>acemd3</name> <gpu_versions> <cpu_usage>1.0</cpu_usage> <gpu_usage>1.0</gpu_usage> </gpu_versions> </app> <project_max_concurrent>2</project_max_concurrent> </app_config> | |
ID: 54090 | Rating: 0 | rate: / Reply Quote | |
Is this useful? | |
ID: 54206 | Rating: 0 | rate: / Reply Quote | |
Not really. Toni stated that with the new acemd3 app and wrapper, that the app will use a full cpu core all on its own without any additional configurations. | |
ID: 54212 | Rating: 0 | rate: / Reply Quote | |
I have a problem with the fact that ACEMD 3 actually utilizes 1 core, as a result, BOINC launches applications more than necessary and this is a big problem, because everything is drowning in context switching. Correct already this disgrace please, how much can you mock then ????? | |
ID: 54903 | Rating: 0 | rate: / Reply Quote | |
Then you must be running your cpu overcommitted to begin with. | |
ID: 54909 | Rating: 0 | rate: / Reply Quote | |
Keith, this is not about changing the actual CPU usage. It is about making BOINC aware. Then you must be running your cpu overcommitted to begin with. That is what L is complaining about. The tasks as sent by the project by default are assigned: And this is what's causing it. As a long time BOINC user you'll know that 0.986 is interpreted as zero which is far from reality. Aurum's app_config addresses that, I do it the same way. But it would be better if we didn't have to override to begin with. The tasks use one CPU, not zero. Tell it like it is and all is well. Reduce the overcommitment of your cpu to other projects. The problem is caused by this project, not others. | |
ID: 54914 | Rating: 0 | rate: / Reply Quote | |
Hi Floyd, you as a long time BOINC user also know that the cpu_usage values are only used for scheduling BOINC resources. | |
ID: 54915 | Rating: 0 | rate: / Reply Quote | |
Hi Floyd, you as a long time BOINC user also know that the cpu_usage values are only used for scheduling BOINC resources. I'm aware of that and I think the original poster is too, but after reading your replies I thought you had misinterpreted their request. Sorry if I got that wrong. Indeed the problem is that with the current numbers BOINC does not schedule any CPU support for the GPU tasks when in fact they need a full core. That doesn't make much difference if you have idle cores but it certainly does when you run a full load of CPU tasks. The request is just to state the GPU tasks need one CPU core, not 0.986 which effectively means no CPU at all, to allow proper scheduling. | |
ID: 54917 | Rating: 0 | rate: / Reply Quote | |
can you cite a source for this? I'm not sure this is the case. please point me to the BOINC documentation or code segment that defines this behavior. the GPU allocation works as intended (0.5 = 0.5, 1=1, 0.33=0.33 and so on) so I have no reason to believe it doesn't account for CPU in increments less than 1 also. ____________ | |
ID: 54918 | Rating: 0 | rate: / Reply Quote | |
Actually Richard commented on this a little while ago somewhere. It depends where you are in the code. | |
ID: 54920 | Rating: 0 | rate: / Reply Quote | |
I'm no source diver and I don't remember seeing any documentation on this, one way or the other. I'm deducing from own observation. Note however that I'm not running the latest clients, please correct me if there were changes recently. the GPU allocation works as intended (0.5 = 0.5, 1=1, 0.33=0.33 and so on) so I have no reason to believe it doesn't account for CPU in increments less than 1 also. Actually GPU scheduling differs from CPU scheduling in several aspects. One difference is that BOINC schedules fractions of GPUs but not fractions of CPU cores. It's a whole core or nothing and 0.986 is not a whole core. 0.986+0.986=1 though, for CPUs. The addition is done before cutting off the fractional part so you'll get one CPU for two tasks (which still is not enough) but none for one task. Of course you won't notice this if BOINC doesn't make other use of the cores, i.e. schedule CPU tasks. | |
ID: 54929 | Rating: 0 | rate: / Reply Quote | |
Currently I fix the problem with crutch: <app_config> <app> <name>acemd3</name> <max_concurrent>1</max_concurrent> <gpu_versions> <cpu_usage>1.0</cpu_usage> <gpu_usage>1.0</gpu_usage> </gpu_versions> </app> </app_config> to the project folder: %ALLUSERSPROFILE%\BOINC\projects\www.gpugrid.net\ It works, but it's crutch. I want the REAL fix from the team. With out this crutch, GPU load only 20-30% because CPU load for acemd only 15-20% of 1 CPU core (S machine) and both machine (S https://www.gpugrid.net/show_host_detail.php?hostid=549893 and H https://www.gpugrid.net/show_host_detail.php?hostid=549849 ) have a big value of context switching. This is a critical issue!!! ____________ | |
ID: 54980 | Rating: 0 | rate: / Reply Quote | |
Actually Richard commented ... Sorry, I've been a bit busy lately. Coming back to this thread, and doing some researching, I came across this page: https://boinc.berkeley.edu/trac/wiki/GpuSync It's ten years old! It describes the problem, speculates about what to do, but so far as I know, nothing further has ever been done. David Anderson, who I'm assuming wrote that document, likes to make BOINC servers as automatic as possible, to avoid administrators having to learn how to twiddle each mysterious knob. Fair enough, but the automatic generation of that 0.9xx figure isn't fit for purpose here. It ought to be 1 for busy-wait, or 'not 1' for interrupt-driven. For the time being, we're in control. It's probably easier for us to add the app_config than for Toni to find and over-ride the automatic setting. But the problem here is aggravated because Toni forgot (or hadn't been trained) to add the <priority>2</priority> line to the job.xml template, when he switched from native apps to using the wrapper. So our GPU apps are running at lowest priority, instead of 'below normal', and users with overcommitted CPUs will take a bigger hit than needed. It's all a bit of a mess. | |
ID: 54981 | Rating: 0 | rate: / Reply Quote | |
------------------- | |
ID: 54982 | Rating: 0 | rate: / Reply Quote | |
Ian and I were having a conversation about this in https://github.com/BOINC/boinc/issues/3764. | |
ID: 54983 | Rating: 0 | rate: / Reply Quote | |
Finally. For host S, I "fixed" the problem with this config: <app_config> <app> <name>acemd3</name> <max_concurrent>3</max_concurrent> <gpu_versions> <cpu_usage>0.3</cpu_usage> <gpu_usage>0.3</gpu_usage> </gpu_versions> </app> </app_config> Unfortunately, the scheduler gives only 2 tasks at a time, so loading only the GPU is only 70%, but this is better than 20% before the start of this experiment. ____________ | |
ID: 54984 | Rating: 0 | rate: / Reply Quote | |
I've never seen 20% GPU usage. I always install an app_config for this project and several others. I cannot imagine why using <cpu_usage>0.3</cpu_usage> is ever a good idea for GG. | |
ID: 54989 | Rating: 0 | rate: / Reply Quote | |
Ian and I were having a conversation about this in https://github.com/BOINC/boinc/issues/3764. not only was it not persistent, but after forcing it in place and after some time, and after trying to download new work, the project was trying to issue a new job.xml file (with the same exact file name) but it would fail because of the way I forced the setting. not having this download finish prevented any new work from running, even though an identical file was already there. so it wont work unless the project fixes that. ____________ | |
ID: 54991 | Rating: 0 | rate: / Reply Quote | |
My priority line is still in the file, with an edit timestamp of around 32 hours ago (many tasks have passed under the bridge in that time!) | |
ID: 54992 | Rating: 0 | rate: / Reply Quote | |
I can't explain why. I did this with Ubuntu 20.04 on my test bench. I opened the file with the standard text editor (gedit) in the GUI, then added <priority>2</priority> and saved and closed the file. restarting BOINC (launched via boincmgr) results in the file being reverted without my edits. | |
ID: 54994 | Rating: 0 | rate: / Reply Quote | |
For comparison: different BOINC environment. | |
ID: 54995 | Rating: 0 | rate: / Reply Quote | |
Hi L, | |
ID: 55090 | Rating: 0 | rate: / Reply Quote | |
I know by what my PC is doing. I'm trying to use 6 out of the 12 CPU threads for BOINC. I had to cut my CPU setting from 50% to 42% to keep my thread usage at 6. From the picture you can see that acemd3 is using 100% of a thread. https://www.dropbox.com/s/meaiqoikn80jiua/boinc_usage_gpugrid.png?dl=0 So, now when my PC switches to an Einstein task (the one marked as 1 CPU), my WCG threads drop to 4 rather than 5. | |
ID: 55130 | Rating: 0 | rate: / Reply Quote | |
So, now when my PC switches to an Einstein task (the one marked as 1 CPU), my WCG threads drop to 4 rather than 5. Einstein gpu tasks will take a cpu out of the 'allocated' cpu limit for their gpu task. Gpugrid tasks do not take a cpu out of the 'allocated' cpu limit. Neither project is right or wrong, they just work differently under the boinc framework. | |
ID: 55131 | Rating: 0 | rate: / Reply Quote | |
Message boards : Frequently Asked Questions (FAQ) : Please set CPU usage to 1 CPU for GPU Acemd tasks.