No new work if a task is suspended

OK.

I don't understand what purpose this would serve.  If you suspend a single task, wouldn't one of the other unstarted tasks in your cache simply start crunching in its place so that the same number of CPU cores would still be loaded?  I could understand it if all other CPU tasks that were waiting to start were suspended as well, or if you had no other CPU tasks ready to start.

If that was in fact what you were doing (suspending all available CPU tasks to reduce the active CPU cores by one), you could have achieved that more easily by reducing the number of cores BOINC is allowed to use by one.  For example, on a quad core host, reduce the % of cores setting by 25%.  This is quick, local, immediate, and just as easy to reverse when you are done.  And you can leave it in place for as long as you like without any interruption to the work flow for either CPU or GPU tasks.

A solution would be to setup a backup project with a zero resource share, that way if you suspend one project, or it hiccups and runs out of work to send,  the backup project will automatically kick in and send you new tasks. BUT it will only send enough tasks to fill the available cpu or gpu cores that are free on your pc. This would NOT help you in the way you did your test because Boinc still thinks you want to use 100% of the cpu cores and you would just get more cpu tasks from the backup project. But you would get gpu tasks too and that would solve this particular problem. I always keep one cpu project and one gpu project as backups, each one different, for when my main project runs out of work etc.

I personally do not run the same project on both my cpu's and gpu's on the same machine, the workunits are much different in crunching time yet the Boinc software doesn't differentiate between them in the cache sizes. Meaning if the gpu tasks are 2 minutes each but the cpu tasks are 30 minutes each I would still get a boatload of cpu units due to the very short gpu workunits.

For the benefit of anyone following this discussion, please be aware that the above doesn't give the full picture.  It doesn't matter at all that there is a difference in crunch times between GPU tasks and CPU tasks.  What does matter is the accuracy of estimates and how estimates are corrected locally by BOINC.

Firstly, consider the difference between the estimated crunch time and the true crunch time.  The project does try to send out tasks where the estimate agrees with the true value as much as possible.  Due to the wide range of differently performing hardware that crunches these tasks, that can be quite difficult to achieve.  Some hosts may be able to do better than the estimate and some may do worse.  It's never going to be perfect.

Secondly, the mechanism used to correct the estimate may be different between different projects.  Einstein uses DCF (Duration Correction Factor).  This works fine, except for one little problem - there is only a single DCF parameter for the entire project.  This is a well known BOINC deficiency that has been around for a long time with little prospect of ever being resolved, so it would seem.

This means that if you run different searches at the one project, and if the relationship of estimate to actual is markedly different between these searches, the DCF can react in opposite directions in a see-saw fashion and BOINC will never be able to settle on a good stable value for crunch time.  This will be most troublesome if GPU tasks finish a lot faster than their estimate and CPU tasks finish much more slowly than their estimate (or vice-versa).

Here is a more detailed version of the above quote that better explains the situation:-

"If the GPU tasks take 2 minutes each with a 4 minute estimate but the CPU tasks are 30 minutes each with a 15 minute estimate I would get a boatload of CPU units because the 'faster than estimated' GPU tasks will have reduced the DCF which in turn has dragged down the already low estimate for CPU tasks, requiring BOINC to request even more of them."

So, if you only take GPU work from Einstein and CPU tasks from elsewhere, there won't be a fluctuating DCF problem and the accompanying instability in CPU task fetch.  Mikey's solution will work nicely.

But that's not the end of the matter.  There is another factor, that compounds the potential over-fetch of CPU tasks where there is a nice fast GPU crunching as well.  By default, when running a GPU task, a CPU core is prevented from running a CPU task.   This is a default project setting for Einstein because GPU tasks can be adversely affected if appropriate, timely support is not immediately available when needed.  For example, in a quad core host, crunching both CPU and GPU tasks,  BOINC would fetch work for 4 cores but only allow 3 to run CPU tasks.  If you decide to crunch 2 concurrent GPU tasks, BOINC will still fetch for 4 cores but only allow 2 to crunch CPU tasks.  This could allow a significant over-fetch of CPU work, even if the CPU work was coming from a different project (so not being affected by an inappropriate DCF).

This form of over-fetch can be eliminated by the use of BOINC's %cores setting and the use of app_config.xml files.  Again using a quad core example, if the %cores was set at 50% and the app_config.xml file set <gpu_usage> to 0.5 and <cpu_usage> to anything less than 0.5 (eg. 0.2), 2xGPU tasks and 2xCPU tasks would be allowed to run with BOINC fetching new CPU tasks for just 2 cores.  The two non-loaded cores would be available for GPU support whenever needed.  Please realise that these settings do not have any impact on the number of CPU cycles that a GPU task will need for support.  The settings are just to allow BOINC to calculate how many tasks of each type to run.  You have to decide what the appropriate numbers should be, essentially by trial and error (and a bit of common sense) :-).