FGRPB1G: CPU usage factor

My experience on this project and Milkyway is that the CPU and GPU requirements are just ESTIMATES.

Sometimes a task may uses less than 50% of a GPU, in which case you could run two or more tasks simultaneously.

Also note that a task may use the CPU and/or GPU heavily for a while and then barely at all for a while.

GPU-Z (Windows) is nice for tracking GPU usage (has a graph). I don't know how to easily track CPU usage for a single  Windows task except by watching the Task Manager.

Einstein@home and Boinc are designed to try and work on all kinds of systems and thus won't run optimally on most systems. There is a few options in Boinc that the user can try to optimize for a particular system.
One of them is using a file called app_config.xml to fine tune the CPU and GPU usage of an app.
Do note that the app in question will always use the resources that it needs, no more and no less, regardless of what the project or the user sets. The settings is only there to tell Boinc how many tasks to start and how to manage the cache of work.

Here's a link to the documentation for using an app_config.xml.

And here's an example that Mr Andersson could try if he feels inclined:

<app_config>
   <app>
      <name>hsgamma_FGRPB1G</name>
         <gpu_versions>
            <gpu_usage>1.0</gpu_usage>
            <cpu_usage>0.1</cpu_usage>
         </gpu_versions>
    </app>
</app_config>

The above code should be placed in a plain text file and saved as app_config.xml (Be sure the there's not an .txt appended) in {BOINC Data directory}\projects\einstein.phys.uwm.edu. The Boinc data directory is listed in the startup messages in the event log. Open Boinc Manager and look under the menu item "Options" to find it.

What the code above would do is tell Boinc that the FGRPB1G tasks will use 1 GPU and 1/10th of a CPU, Boinc will then use this information together with the same kind of info for other tasks to schedule (start) enough tasks to use all available resources, both CPU and GPU.
What's not obvious is that the task might need more or less resources than the settings are telling Boinc and thus the tasks might not run optimally. The community wisdom at Einstein says that Nvidia GPU tasks needs to have a CPU thread reserved as support or the performance of the task is impaired, but AMD GPU tasks can make due with less.
For any given system one needs to experiment to find the most productive state. What this entails is trying different settings and recording the results, then comparing them and choosing the one that yields the best results.

Do take note that once an app_config.xml has been used then if one want's to back out and use the project supplied settings one has to reset the project and thus lose any tasks in the cache. Setting "No new tasks" and running down the cache would be the preferred way.

You might thinks it's working perfectly but it looks like it's far from optimal.

You should read again what Holmis wrote and think about the need to experiment.  I had a look at some of the results from your host with the HD7700 series GPU.   I saw results from a day or two ago where the elapsed time varied between 2400 secs for one task and up to 3600 secs for some others.  I then looked at the most recently returned results which would be after your installation of the app_config.xml.  The crunch times are now varying between 4000 secs and 4600 secs.  I feel fairly confident that would be from the 0.1 CPU setting.  I imagine BOINC is now allowing you to run CPU tasks on all your CPU cores which means the poor discrete GPU task has to fight for service (even though it only needs a tiny bit of service).

You really need to understand that setting 0.1 for ncpus does NOT guarantee that the GPU task will get what it needs and (particularly) when it needs it, even though its needs may be quite small.  What it DOES guarantee is that BOINC is not going to be restricted in any way from allocating CPU work to all the cores.  And when it does that, your GPU task is highly likely to run in a sub-optimal manner.  The project defaults seem to give you a much better result than what you have currently chosen.

I'm guessing your GPU may be a 7750 or 7770.  If you would like to know what a 7770 GPU should be capable of, take a look at the results for this host.  It's a 2009 vintage Phenom II and I installed the 7770 in it when I first started GPU crunching here - probably around 2010-2011.  It has run 24/7 ever since.  Please notice how relatively uniform the crunch times are.  Classic indicators of sub-optimal crunching are crunch times that show considerable variation like yours do.

If you are prepared to experiment a little to improve performance, you can make a simple adjustment to your local preferences through BOINC Manager and leave the app_config.xml file as it is.  That adjustment would be to change the % of cores that BOINC is allowed to use from 100% (if that is what you have it set at) to 87.5%.  You will have 1 less CPU task running but the GPU task should run much faster again.

There is a further potential issue you need to think about.  You have an active internal (Intel) GPU that would also need some CPU support.  I have never used one of these so have no suggestions to offer about how to properly support it along with the discrete GPU.  I don't even know if there is a default for how much CPU support BOINC will budget for when Intel GPU tasks are running.  The CPU time component is quite small so perhaps nothing is budgeted.

In any case, it actually seems to be pretty stable at the moment so perhaps it will continue that way.  The crunch times for it might improve a bit if you make the change I've suggested.  One experiment you should consider is to temporarily suspend all the Intel GPU tasks for long enough to see what it does to the discrete GPU crunch times and how it affects the number of CPU cores that are running other CPU only tasks.

I'd certainly be interested to hear how you go if you try some of these experiments.

I've had a long/hard look at the OpenCL standard, naturally it only specifies an interface not the implementation. One can choose to invoke some API calls as blocking, or non-blocking where one then relies on querying an event object to synchronise activity. That is : OpenCL has no concept of threads and one needs a CPU thread to launch kernels on the GPU via enqueued requests. What is certain is that NVidia implements OpenCL using CUDA, and thus lies both lesser efficiency and probably the need for other thread(s). The detail is within the driver, which then must determine the true CPU usage fraction ( as opposed to some declared ratio ) from its main thread and whatever others it may create. For the brave : profilers do exist .... 

Cheers, Mike.

Further research indicates that the 1 CPU allocation per 1 GPU is an Nvidia OpenCL implementation 'bug' present since 2011. It's a busy wait scheme ie. the CPU thread spins while awaiting for a kernel to finish, and doesn't yield otherwise. How inefficient this is depends upon the duration of the kernels, quicker kernels will engage the CPU more as they complete. An alleged reason for this design choice is that busy wait ( "Are we there yet ?" ) also equals instant response upon completion. However the only known mechanism to turn this behaviour off is to use CUDA ( the cudaDeviceScheduleYield option and CudaUseBlockingSync platform property ). IMHO it is probably an intended 'feature' rather than an error.

Since we're still talking about this in late 2018, I suspect pigs-may-fly/hell-freezes-over/cows-come-home before NVidia alters this.

Cheers, Mike.

( edit ) Presumably then, the extra thread needed for NVidia cards is replete with non-blocking CUDA calls.

( edit ) FWIW : OpenCL kernels are not equivalent to CPU threads. A kernel is ( typically/probably ) instantiated onto distinct GPU compute units, whereas a CPU thread is a matter of time slicing a given CPU core. One is a spatial division of labour the other is temporal.