Why quota of 40 per CPU core?
Just a day or two ago I completed a pretty strong effort to assess the productivity and power consumption of a host with one GTX 460 GPU card and an i5-2500K CPU (four cores, no hyperthreading). I looked at simultaneous GPU tasks from zero through three, and CPU tasks from zero through four. While the general rule was that two or three GPU tasks was better than anything else by a lot, and did not vary so much within that group, the higher CPU task options suffered more than I expected, as they degraded GPU output, required more CPU time per task completion, and had considerably inferior incremental power efficiency (in fact often negative!). Holding the GPU tasks running constant at three, the peak output was with two CPU tasks running, while the four CPU task option actually gave less credit/day than the zero CPU task option--with considerably inferior power consumption, and probably much worse user interactive responsiveness.
Weighing all considerations, I concluded that I wanted to run with 3 GPU tasks and one CPU task, with the GPU running BRP and the CPU running GW work.
Within hours I got a rude awakening--this configuration can't come close to keeping itself fed with newly assigned work, as the limit of 40 new tasks per day per active CPU core throttles delivery. As this configuration has an indicated daily throughput of 62.2 GPU tasks and 6.8 CPU tasks, the indicated daily deficit of task assignment is thirty tasks.
Even stepping up to three GPU and two CPU tasks, which was actually the highest output configuration I tested, gives a very modest daily net task queue gain of 7.1 tasks--so a miserly 10%/ day recovery rate in the case of outages at the project, lost communication at any point between, and certain types of trouble on my own host.
In casting about for solutions, I noticed that if one attempted to approximate the 3 GPU/1 CPU configuration by setting the BOINC preferences to allow 50% of CPUs (half of four is two in my case) and to allow at most 50% of CPU time (labelled as a CPU heat reducing provision), one would get similar total throughput, but be allowed 80 tasks/day.
Sadly this alternate is in fact a bit less productive--probably because the CPU throttling scheme employed slightly increases average response time of the CPU application which supports each GPU tasks. It is sad to give up 2% on both output and power efficiency just to obtain a marginally adequate supply of work.
I confess I don't know the history of this limit, nor why it gives full credit to each CPU core allowed to work, even if heavily throttled by a power reduction duty cycle limit, while giving zero credit to GPUs, which when present often absolutely dominate the real productivity.
While I don't for a moment think that my personal situation itself warrants a change in this project limit, I've described it in some detail just in case the window is open to reconsider the limit, the value imposed, or the method of calculation. It would be a pity to discourage GPU participants.
[edited for clumsy wording]