Every time a set of tasks switches itself into high priority it takes up all system resources disabling at least 1 GPU sometimes 2. GPUs should have first priority over all CPU tasks. This needs to be fixed.

I have seen the question asked before but never answered and replies are disabled, is there an option yet to disable this? Or at least fix the GPU priority level.

Why do you believe faster GPUs should have priority over slower CPUs? If anything, it should be the other way around as CPUs can take quite a while to do the same task a GPU can in so much a shorter time.

With that said, mind answering some of the basic questions so we have some knowledge of your system?

---

Every time a set of tasks switches itself into high priority it takes up all system resources disabling at least 1 GPU sometimes 2. GPUs should have first priority over all CPU tasks. This needs to be fixed.

I have seen the question asked before but never answered and replies are disabled, is there an option yet to disable this? Or at least fix the GPU priority level.

Sometimes having your cache set too high can cause tasks to run at high priority because BOINC thinks they won't finish before the due date. As a test try lowering your cache to 0 and see if the tasks running high priority go back to normal. If they do then it's a trial and error thing to figure out how high to set your cache so ones that are running don't go into high priority mode. You may have to change cache settings as you change projects. Good luck.

Why do you believe faster GPUs should have priority over slower CPUs? If anything, it should be the other way around as CPUs can take quite a while to do the same task a GPU can in so much a shorter time.

With that said, mind answering some of the basic questions so we have some knowledge of your system?

For the first question: GPUs can massively outperform cpus as you stated, so for the sake of production, it should have priority. Completely disabling, for arguments sake, what is equivalent to 100 cpu cores just for one cpu core doesn't make much sense to me.

onto the basics: it just seems to be prime grid right now (although I have had the same issue with climate), but the subproject is TRP LLR from the recent challenge, some of the tasks have a day or two to finish (take 12 hours to run), some are due in the next 12 but are half way done. But when one gets triggered it triggers all tasks by PrimeGrid to go high priority.

I have an i7-4820k so 8 cpu tasks are possible but with 2 GPU's it's generally running 6 tasks. (EVGA GTX 780 sc and EVGA GTX 760 sc) When it switches to High Priority it makes it 7 or 8 tasks and then kills the use of one or both of my GPUs.

I have also tried limiting the number of running tasks per project using both project max concurrent and max concurrent. Neither does the trick, project max concurrent = same exact issue just less running tasks, max concurrent = any other primegrid task joins in at high priority.

TheBeast

1			10/10/2014 12:28:03 PM	Starting BOINC client version 7.4.22 for windows_x86_64	
2			10/10/2014 12:28:03 PM	log flags: file_xfer, sched_ops, task	
3			10/10/2014 12:28:03 PM	Libraries: libcurl/7.33.0 OpenSSL/1.0.1h zlib/1.2.8	
4			10/10/2014 12:28:03 PM	Data directory: U:\BOINC_DATA	
5			10/10/2014 12:28:03 PM	Running under account Devlin	
6			10/10/2014 12:28:03 PM	CUDA: NVIDIA GPU 0: GeForce GTX 780 (driver version 344.11, CUDA version 6.5, compute capability 3.5, 3072MB, 2749MB available, 4698 GFLOPS peak)	
7			10/10/2014 12:28:03 PM	CUDA: NVIDIA GPU 1: GeForce GTX 760 (driver version 344.11, CUDA version 6.5, compute capability 3.0, 2048MB, 1957MB available, 2620 GFLOPS peak)	
8			10/10/2014 12:28:03 PM	OpenCL: NVIDIA GPU 0: GeForce GTX 780 (driver version 344.11, device version OpenCL 1.1 CUDA, 3072MB, 2749MB available, 4698 GFLOPS peak)	
9			10/10/2014 12:28:03 PM	OpenCL: NVIDIA GPU 1: GeForce GTX 760 (driver version 344.11, device version OpenCL 1.1 CUDA, 2048MB, 1957MB available, 2620 GFLOPS peak)	
10			10/10/2014 12:28:03 PM	Host name: TheBeast	
11			10/10/2014 12:28:03 PM	Processor: 8 GenuineIntel        Intel(R) Core(TM) i7-4820K CPU @ 3.70GHz [Family 6 Model 62 Stepping 4]	
12			10/10/2014 12:28:03 PM	Processor features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss htt tm pni ssse3 cx16 sse4_1 sse4_2 popcnt aes f16c rdrandsyscall nx lm avx vmx tm2 dca pbe fsgsbase smep	
13			10/10/2014 12:28:03 PM	OS: Microsoft Windows 8: Professional x64 Edition, (06.02.9200.00)	
14			10/10/2014 12:28:03 PM	Memory: 15.94 GB physical, 31.94 GB virtual	
15			10/10/2014 12:28:03 PM	Disk: 465.76 GB total, 5.60 GB free	
16			10/10/2014 12:28:03 PM	Local time is UTC -4 hours	
17			10/10/2014 12:28:03 PM	VirtualBox version: 4.3.12	
18	climateprediction.net	10/10/2014 12:28:03 PM	Found app_config.xml	
19	GPUGRID	10/10/2014 12:28:03 PM	Found app_config.xml	
20	PrimeGrid	10/10/2014 12:28:03 PM	Found app_config.xml	
21	World Community Grid	10/10/2014 12:28:03 PM	Found app_config.xml	
22			10/10/2014 12:28:03 PM	Config: use all coprocessors	
23	climateprediction.net	10/10/2014 12:28:03 PM	URL http://climateprediction.net/; Computer ID 1326531; resource share 5	
24	pogs	10/10/2014 12:28:03 PM	URL http://pogs.theskynet.org/pogs/; Computer ID 35477; resource share 200	
25	SETI@home	10/10/2014 12:28:03 PM	URL http://setiathome.berkeley.edu/; Computer ID 7275014; resource share 25	
26	Enigma@Home	10/10/2014 12:28:03 PM	URL http://www.enigmaathome.net/; Computer ID 130751; resource share 10	
27	GPUGRID	10/10/2014 12:28:03 PM	URL http://www.gpugrid.net/; Computer ID 183361; resource share 100	
28	PrimeGrid	10/10/2014 12:28:03 PM	URL http://www.primegrid.com/; Computer ID 433482; resource share 100	
29	World Community Grid	10/10/2014 12:28:03 PM	URL http://www.worldcommunitygrid.org/; Computer ID 3031261; resource share 25	
30			10/10/2014 12:28:03 PM	General prefs: from http://bam.boincstats.com/ (last modified 15-Sep-2014 00:41:27)	
31			10/10/2014 12:28:03 PM	Computer location: home	
32			10/10/2014 12:28:03 PM	General prefs: no separate prefs for home; using your defaults	
33			10/10/2014 12:28:03 PM	Reading preferences override file	
34			10/10/2014 12:28:03 PM	Preferences:	
35			10/10/2014 12:28:03 PM	   max memory usage when active: 12243.62MB	
36			10/10/2014 12:28:03 PM	   max memory usage when idle: 12243.62MB	
37			10/10/2014 12:28:03 PM	   max disk usage: 6.44GB	
38			10/10/2014 12:28:03 PM	   (to change preferences, visit a project web site or select Preferences in the Manager)	
39			10/10/2014 12:28:03 PM	Not using a proxy	

Sometimes having your cache set too high can cause tasks to run at high priority because BOINC thinks they won't finish before the due date. As a test try lowering your cache to 0 and see if the tasks running high priority go back to normal. If they do then it's a trial and error thing to figure out how high to set your cache so ones that are running don't go into high priority mode. You may have to change cache settings as you change projects. Good luck.

I will give that a try and see if the issue goes away. I do like have some built up as lately servers have been going offline for upgrades and maintenance, or for when they run out/load projects.

Sometimes having your cache set too high can cause tasks to run at high priority because BOINC thinks they won't finish before the due date. As a test try lowering your cache to 0 and see if the tasks running high priority go back to normal. If they do then it's a trial and error thing to figure out how high to set your cache so ones that are running don't go into high priority mode. You may have to change cache settings as you change projects. Good luck.

I will give that a try and see if the issue goes away. I do like have some built up as lately servers have been going offline for upgrades and maintenance, or for when they run out/load projects.

I know what you mean about server issues and running out of work. What I suggested won't fix the problem but it is a work around that I have had success with although not 100% of the time. Good luck.

As a wild guess, I suspect it is an issue, feature, bug, documentation of how the CPU cores are counted with a GPU task. If you are doing work on projects with multi CPU projects, BOINC strictly enforces core counts. So if you end up with those multi CPU projects all going at once, they take exactly 100% of the cores and the fractional % of a core GPU job can't run. If you have projects that only use one core each, BOINC does not strictly enforce core counts and the fractional % of a core GPU job is allowed to run; an over commitment.

I suspect what is happening is you have a project that is multi-core and has short deadlines so it goes into EDF mode right away. That makes you think the issue is EDF mode, but it really is a mix of GPU and multi-core projects.

You can try to "fix" this feature by setting your cache towards zero so that less work is put in your buffer, but that only helps up to a point. The other "fix" is to restrict BOINC so that does not use 100% of the cores, say 99% not 100%. That should make a project like Milkyway that will grab all cores that it can to count one less core. Then the fractional part of that core not in use is free to be used by BOINC to run a GPU task.

Oh, don't change the core counts if you have tasks in the cache that are expecting all the cores, or you might end up with them aborting as they no longer have the resource to run. Drain your cache first or make sure you only have one core tasks in it.

---

The other "fix" is to restrict BOINC so that does not use 100% of the cores, say 99% not 100%. That should make a project like Milkyway that will grab all cores that it can to count one less core. Then the fractional part of that core not in use is free to be used by BOINC to run a GPU task.

That was the workaround I was thinking of, reducing the number of CPU cores available to BOINC by 1. I do believe that the GPU priority also varies by project, and/or they have different resources so that a different project's tasks can make higher use of your GPU with less resources. Moo! is one example of a GPU project that isn't too resource-heavy, I get good GPU utilization with it even with 100% CPU utilization on my R9 280X.

---

My Detailed BOINC Stats

The other "fix" is to restrict BOINC so that does not use 100% of the cores, say 99% not 100%. That should make a project like Milkyway that will grab all cores that it can to count one less core. Then the fractional part of that core not in use is free to be used by BOINC to run a GPU task.

That was the workaround I was thinking of, reducing the number of CPU cores available to BOINC by 1. I do believe that the GPU priority also varies by project, and/or they have different resources so that a different project's tasks can make higher use of your GPU with less resources. Moo! is one example of a GPU project that isn't too resource-heavy, I get good GPU utilization with it even with 100% CPU utilization on my R9 280X.

Not sure if you reduce by one that solves the problem. I think you need to reduce by a fraction. I think it is integer math that is causing the issue. But try it and let us know.

---

As a follow up to this:

It looks like the 2 ways to curb it are setting it to zero days for cache settings as was suggested, but that leads to downtime :(

Or by using project max concurrent settings in app config to force a limit. But then that requires constant adjustments and has a set of problems all of it's own. And can still cause issues when 2 projects go high priority, especially with varying gpu requirements.

Changing the percentage of cores used or core numbers leads to the same issue with less processing being done.

I wish GPU just had priority, or that there was a no high priority flag.

---

"Science is much more than a body of knowledge. It is a way of thinking." -Carl Sagan

I don't understand why tasks running in high priority would disable GPU processing. Does it change something with the process' priority in the OS as well as in BOINC? I'm not seeing how/why high priority would take away the 0.1 CPUs that most GPU tasks use.

I don't understand why tasks running in high priority would disable GPU processing. Does it change something with the process' priority in the OS as well as in BOINC? I'm not seeing how/why high priority would take away the 0.1 CPUs that most GPU tasks use.

It is how you add the cores up and what the project requests for cores. It gets complicated, but essentially it works out to this, you have say 8 cores and 8 jobs in EDF. Where is BOINC going to get the 0.1 core to run the GPU task? If you have 8 cores and 6 tasks in EDF mode, BOINC will run one more CPU task and the GPU. Well, that is what it is supposed to do, however that isn't what happens always. If all the tasks are 1 core tasks, BOINC will over commit and run 8 + the GPU. But if you have one 8 core task it will not over commit and the GPU task won't run, EDF mode or not.

So depending on your project mix and what goes into EDF it can shut down the GPU. So if you run a project mix with multiple core jobs to get the best throughput you need to tell BOINC you have just slightly less than an integer number of cores say by letting it use 99% of the cores not 100%. Seems counter intuitive, but the GPU is so much faster than the CPU, sacrificing part of the CPU is nothing compared to keeping the GPU going all the time.

---

I don't understand why tasks running in high priority would disable GPU processing. Does it change something with the process' priority in the OS as well as in BOINC? I'm not seeing how/why high priority would take away the 0.1 CPUs that most GPU tasks use.

It is how you add the cores up and what the project requests for cores. It gets complicated, but essentially it works out to this, you have say 8 cores and 8 jobs in EDF. Where is BOINC going to get the 0.1 core to run the GPU task? If you have 8 cores and 6 tasks in EDF mode, BOINC will run one more CPU task and the GPU. Well, that is what it is supposed to do, however that isn't what happens always. If all the tasks are 1 core tasks, BOINC will over commit and run 8 + the GPU. But if you have one 8 core task it will not over commit and the GPU task won't run, EDF mode or not.

So depending on your project mix and what goes into EDF it can shut down the GPU. So if you run a project mix with multiple core jobs to get the best throughput you need to tell BOINC you have just slightly less than an integer number of cores say by letting it use 99% of the cores not 100%. Seems counter intuitive, but the GPU is so much faster than the CPU, sacrificing part of the CPU is nothing compared to keeping the GPU going all the time.

Huh. I've never had tasks run in high priority so I never see this. My computer is always able to run 8 CPU tasks and 1 GPU task.

I don't understand why tasks running in high priority would disable GPU processing. Does it change something with the process' priority in the OS as well as in BOINC? I'm not seeing how/why high priority would take away the 0.1 CPUs that most GPU tasks use.

It is how you add the cores up and what the project requests for cores. It gets complicated, but essentially it works out to this, you have say 8 cores and 8 jobs in EDF. Where is BOINC going to get the 0.1 core to run the GPU task? If you have 8 cores and 6 tasks in EDF mode, BOINC will run one more CPU task and the GPU. Well, that is what it is supposed to do, however that isn't what happens always. If all the tasks are 1 core tasks, BOINC will over commit and run 8 + the GPU. But if you have one 8 core task it will not over commit and the GPU task won't run, EDF mode or not.

So depending on your project mix and what goes into EDF it can shut down the GPU. So if you run a project mix with multiple core jobs to get the best throughput you need to tell BOINC you have just slightly less than an integer number of cores say by letting it use 99% of the cores not 100%. Seems counter intuitive, but the GPU is so much faster than the CPU, sacrificing part of the CPU is nothing compared to keeping the GPU going all the time.

Gary, I don't believe Devlin85 is running any multi-threaded work. These are all single thread apps that he is experiencing this with. So, all POGS work for example. Those are CPU only right now and they are all single threaded. They are going into high priority mode and pausing GPU's. Per discussions with him in his teams forums, it appears reserving a core for the GPU's isn't fixing the issue. http://forums.evga.com/Tasks-Running-High-Priority-are-Disabling-GPUs-m2232441.aspx

---

I don't understand why tasks running in high priority would disable GPU processing. Does it change something with the process' priority in the OS as well as in BOINC? I'm not seeing how/why high priority would take away the 0.1 CPUs that most GPU tasks use.

It is how you add the cores up and what the project requests for cores. It gets complicated, but essentially it works out to this, you have say 8 cores and 8 jobs in EDF. Where is BOINC going to get the 0.1 core to run the GPU task? If you have 8 cores and 6 tasks in EDF mode, BOINC will run one more CPU task and the GPU. Well, that is what it is supposed to do, however that isn't what happens always. If all the tasks are 1 core tasks, BOINC will over commit and run 8 + the GPU. But if you have one 8 core task it will not over commit and the GPU task won't run, EDF mode or not.

So depending on your project mix and what goes into EDF it can shut down the GPU. So if you run a project mix with multiple core jobs to get the best throughput you need to tell BOINC you have just slightly less than an integer number of cores say by letting it use 99% of the cores not 100%. Seems counter intuitive, but the GPU is so much faster than the CPU, sacrificing part of the CPU is nothing compared to keeping the GPU going all the time.

Gary, I don't believe Devlin85 is running any multi-threaded work. These are all single thread apps that he is experiencing this with. So, all POGS work for example. Those are CPU only right now and they are all single threaded. They are going into high priority mode and pausing GPU's. Per discussions with him in his teams forums, it appears reserving a core for the GPU's isn't fixing the issue. http://forums.evga.com/Tasks-Running-High-Priority-are-Disabling-GPUs-m2232441.aspx

Don't know about some of the projects he is attached too.

It isn't really "High Priority" but Earliest Deadline First. There is no change in priority, just a change in which job is picked to run first. The O/S has no clue anything is different and to the O/S all the jobs are still are low priority.

Other than the order in which particular jobs run, there is no change, that is why I strongly suspect that multi-threaded jobs are afoot. Now it is possible DA made some change to the BOINC scheduler that I'm not aware of ... but last I knew CPU and GPU were two different queues and EDF in the CPU queue did not force integer math on the number of CPUs.

---

Before the next person goes and quotes everything Gary here quoted and answered to, can we please make sure to cull the text out that you're not answering to? Makes for easier reading on various screens, including mobile devices. With thanks.

---