GPU utilization benchmark

I had been running three GPU jobs using app_info. After a long wait running down my queue of older work, I removed app_info and got a good start using the new mechanism with count of 0.33 giving three GPU jobs.

But now I am trying to check out two GPU job behavior, and it does not seem to be listening. I've checked the location (a.k.a. "venue"), changed the location-specific "GPU utilization factor of BRP apps" from 0.33 to 0.5, and pressed the "update" button for Einstein. When the next units to start up started as a triple, I tried shutting down boincmgr and restarting. No joy. Shut down the computer, counted to thirty, and rebooted. Still three jobs. Did another user-requested Update. Still three jobs. Although I believed that this is not a local preference item and that I had no local preference set, I nevertheless went into the boincmgr preference dialog and commanded "clear". Still no joy (i.e. three GPU Einstein jobs).

Anyone else see some problem in changing the specified number of GPU jobs? Any secret sauce? Any idea what I most likely did wrong?

Not quite, but related. The value lives in the section in client_state.xml, and that section is only re-transmitted from the server to the client when new work is allocated. But once transmitted, it applies to all work in the cache, old and new.

@ archae86 - which host are you talking about, and when did you try this? 3409259 last received work at 19 Mar 2012 0:46:24 UTC, 4234243 at 19 Mar 2012 12:20:35 UTC (unless there are later allocations lurking on later pages - I didn't check).

I have the same issue with one computer that I want to run only one WU per GPU... Since Ive changed the venue it has not received any new BRP WU but it got some other tasks from Einstein and the client_state is still showing 0.5 instead of 1 in the cuda count.

Should I have to wait until a new BRP is downloaded to get the count changed in the client_state?

To get the change automatically, yes.

In my case I was wrong about my quota exhaustion forcing me to wait until midnight UTC. While I distinctly recall that in the past at least some quota limits were released at that time, in this case it appears that the 80 per day limit set a 24-hour timer from the moment it went into force. Only this morning was I able to get new work, and even after I'd been allocated new BRP units and they had started downloading, three GPU tasks continued executing, apparently switching to the desired two when the first (of a couple of dozen) BRP tasks finished downloading to my host. So now the experiment in varying number of GPU and CPU tasks can continue.

While I'm mentioning the 80 limit, I think I saw another awkward consequence. As BRP work was recently much more routinely available than the GW work for my CPU slots and my host was pretty hungry after going to zero, there was a tendency to fulfill nearly all the 80 quota with BRP, leaving me with a very small amount of pending CPU work when the quota gate closed, sometimes taking my CPU to idle later. I'd have guessed there to be separate maximum daily download quotas for CPU and GPU, but in this instance it appeared not.

I think you could get a lot of us to agree that the scheduler finds many common situations puzzling.

One trick I've used to avert undesired High Priority execution is to place most of the queue tasks on suspend. It appears that in estimating schedule risk it does not count the suspended stuff. This does, however, stop new downloads on that project until reversed.

Or, you can just let it work itself out of trouble. But in High Priority panic, often it seems to start job after job, run them just a little, then skip on to another--often not even the soonest deadline. So I'm not happy with the "just let it work out" solution in the case of priority panics caused by sudden estimated performance changes.