How to control the FGRP3 / BRP4G / BRP5 mix for GPU endowed hosts

You can ignore all of this if any of these are true

• * You don't have a host with a GPU capable of crunching.
  * You have a GPU but it is one of the recent integrated Intel HD4x00 ones. Sorry, I'm not addressing those here.
  * You have a GPU but are quite happy to take what the project sends.
  * You have no desire to run multiple concurrent tasks on your GPU.
  * You have a GPU but don't want to prevent FGRP3 GPU tasks.
  

If you are still reading, you are probably interested in making the most efficient use of a discrete GPU. Please note that 'efficient' doesn't mean maximum RAC. If you think it does, you shouldn't be crunching this project. These notes are all about choosing the combination of apps that will most effectively use the resources you are donating.

Running multiple GPU tasks concurrently is a good way to improve your host's output but at the expense of additional power draw and heat. As this note is not about the mechanics of running multiple concurrent tasks, I am going to assume you already know about the 'GPU utilization factor' pref setting. I am also going to assume you understand that the new FGRP3 GPU app is still in development and that it needs so much CPU support that GPU loading will be a lot lower than what you are used to with previous BRP4/5 apps. If you don't understand this, please read the announcement thread in Technical News.

The particular scenario I want to address is how to run FGRP3 CPU tasks only whilst preventing FGRP3 GPU tasks from ever being downloaded in the first place. I assume there will be volunteers who wish to keep the current and more efficient BRP4/5 type tasks for their GPUs whist choosing exactly what to run on any spare CPU cores.

I have a lot of GPU endowed hosts. I've spent quite a bit of time tuning each one to crunch efficiently. I want to run the most efficient combination of apps and for me (until FGRP3 GPU improves) that means BRP4/BRP5 on the GPU and FGRP3/S6CasA on the CPU cores. I've used all venues (default, home, school, work) to set up different GPU utilization factors of 1, 0.5, 0.33, 0.25, respectively, which covers the most likely range. I have other specific factors in choosing which apps I run personally, but I'm attempting to make these notes as general as possible.

There have been a couple of recent developments that make it possible to run FGRP3 CPU tasks without having to run FGRP3 GPU. The latest apps have the as part of their name and this is crucial. The latest recommended BOINC (7.2.42) is also crucial. You need to use the most recent incarnation of app_config.xml which is documented (sketchily) at the bottom of this page.

In the last couple of hours I found some time to upgrade some of my linux boxes to 7.2.42 and to compose the app_config.xml file I thought might work. It would have been nice to have more detail in the documentation :-). I chose to try this out on a machine with an AMD HD7850 GPU and an i3-2120 CPU (Sandy Bridge) - 4 HT cores. The machine was in the work venue and was running BRP5 4x on the GPU. This automatically reserves two CPU cores. I was running an entirely separate project (POGS) on the 2 spare CPU cores. Below is the app_config.xml file that I have written to allow me to run FGRP3 CPU tasks.

[pre]

hsgamma_FGRP3
2

0.25
0.5



hsgamma_FGRP3
FGRPSSE
1


einsteinbinary_BRP5
4

0.25
0.5

[/pre]
The documentation says that overrides but it still was uncomfortable to leave in stuff about . None of this was shown as optional ([]) so I left it all in. I figured I might need the set to 2 so I was happy to have that in. I made the assumption that not setting a for the GPU app would be sufficient to preclude GPU tasks but it would have been nice to read something like that in the documentation :-).

So I placed the above file in the EAH project directory and used the 'read config files' control in the manager. The event log didn't complain about syntax errors but it did complain that "Entry in app_config.xml for app 'hsgamma_FGRP3', plan_class 'FGRPSSE' doesn't match any app versions". I wasn't too concerned because how would the current BOINC client know about this app when it hadn't been running it before. It had previously run FGRP3 but before the plan_class stuff had come along.

So I set the cache size to a low value to prevent over fetch, changed the venue from 'work' (FGRP3 disabled) to '---' (default) (FGRP3 enabled) and hit 'update'. The client grabbed the new venue but again complained about the app/plan_class. I increased the work cache setting to trigger work fetch and was rewarded with 7 CPU tasks and no GPU tasks. Looks like everything is working the way I had hoped.

I promoted one of the new CPU tasks and have been watching it occasionally, noting progress. The tasks were estimated to take around 24 hours which is around 3x what they should take for this CPU. The estimates are always way too high anyway and I presume this is an artifact of running GPU tasks 4x. I presume BOINC is not smart enough to make allowances for the 'slowness' of an individual GPU task :-). A CPU task finishing always lowers estimates on all EAH tasks by the normal amount you would expect and then along comes a GPU task and cranks them back up again.

The first task was 0.3% complete after 6 mins, 4.2% after 60 mins and 10.3% after 90 mins, ie 6.1% progress in the last 30 minutes. This translates to a full run time of just over 8 hours - probably at least 8.5 hours when the extra time for followup calculations (now allowed for in the very slow start) is added. It's worthy of note that a lot of the first hour was taken up with slow but continuous (changing every second) progress. By the time I looked again at the hour mark, progress wasn't continuous but the interval between progress steps wasn't inordinately long. I don't think too many people will think things are stalled :-).

One other point I should mention. I made the assumption that app_config.xml would override project pref settings. This host is now in a venue where the GPU utilization factor is 1. However there are still 4 GPU tasks crunching. I haven't downloaded new GPU work and wont be until my ISP's next 'off-peak' period cpmes around. I can easily wait till then to confirm (or otherwise) the assumption.

Everything continues to look good so I hope these notes might be useful to others. If you are running a different number of CPUs/concurrent GPU tasks, you will need some changes to the details.

EDIT:
I guess I should point out that, in order to keep things simple, I chose to have only one GPU app (BRP5) for this host. It should be easy to substitute BRP4 for BRP5 or even to have both if you so desired.