Message boards : BOINC client : task switching limitation when running multiple tasks on same GPU?
Message board moderation
Author | Message |
---|---|
Send message Joined: 27 Jun 08 Posts: 641 |
I occasionally have a problem keeping GPUs fully occupied on the best "paying" project and have been assigning various resource values to ensure the best project is running at all times. question: If one has "switch between tasks" set to one hour, but (Milkyway for example) the tasks take only 3 minutes to complete, and that video board is running 10 tasks concurrently, will a task switch ever occur to cause the GPU to switch to another project? Here is the problem I ran into that caused the question: I have set Gpugrid to resource %100 on a GTX1070 which is a pretty good CUDA processor. Occasionally, Gpugrid runs out of data as it is a scientific project. To prevent an idle system, I have set Einstein to resource %0 so that it will run when Gpugrid is not sending WUs. Einstein WUs take 15 or so minutes and I am running 4 concurrently. Einstein downloads and runs only if Gpugrid is out of data. This system has three of the 1070s and occasionally I discover that 12 Einstein are running and I can only get a Gpugrid task if I suspend the Einstein project and request a project update for Gpugrid. Possibly, this scheduling problem it with the project and not the boinc program as Gpugrid may just happen to be out of data at the exact time boinc asks for some. However, I have seen another of my systems, with a slower single gtx1060, get 1 or even 2 Gpugrid tasks while the system with the three 1070 keeps running Einstein and downloading more Einstein to keep its queue full instead of asking for a Gpugrid task. Things get worse when both Gpugrid and Einstein are out of data simultaneously. I then run Collatz, a math project that is never out of data, but that can be the subject of a different thread. |
Send message Joined: 27 Jun 08 Posts: 641 |
I think this is a case of the project (GPUGrid) not always having work units available. I found that if I wait long enough eventually they will arrive and the low priority for the other projects eventually ensures they will download and run. I can speed things up by suspending other projects and requesting an update but I have other things to do besides babysit. Keeping a short queue size also helps as it ensures checking for work more often. |
Send message Joined: 5 Oct 06 Posts: 5134 |
Agreed. |
Send message Joined: 1 Jul 16 Posts: 146 |
I run something similar, most of the time its GPUGrid and E@H as a backup. I set GPUGrid at 1000% and E@H at 0% just to widen the gap. Whenever I've downloaded a GPUGrid task after being out tasks for a bit, no more E@H tasks download for that card. I actually run 2 concurrent tasks for both those projects and E@H only downloads work if there is no GPUGrid work. |
Copyright © 2025 University of California.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License,
Version 1.2 or any later version published by the Free Software Foundation.