ATI AP stops NVIDIA/CPU from getting WUs?

[Frizz]

I have a host with a GT240 (for CUDA MB), a HD5770 (ATI Astropulse) (and of course a CPU  )

Last week I ran dry of CUDA and CPU tasks. All I had was shitloads of ATI AP tasks.

So I detached and re-attached to SETI.

First thing after I attached was I got 61 AP units at once. An hour later some CUDA and CPU tasks.

To prepare for the outage I wanted to get some more units (pressed update several times with automated script). But all I got was even more ATI AP units. No more CUDA/CPU units.

Has someone experienced a similar problem?

What to do?

[EDIT]: As a little workaround a rescheduled all CPU units to GPU, hoping to get some new CPU units in - and then reschedule them back to GPU. Just to be prepared for the outage. Works - sort of. But pain in the ass to manually mess around.

[Ghost0210]

looks like claggy reported the same issue here http://lunatics.kwsn.net/gpu-testing/astropulse-hybrid-cpu-ati-gpu-build-for-windows.msg30154.html#msg30154

[Frizz]

looks like claggy reported the same issue here http://lunatics.kwsn.net/gpu-testing/astropulse-hybrid-cpu-ati-gpu-build-for-windows.msg30154.html#msg30154

Not really. My WUs do crunch on the GT240 - I just don't get new CUDA WUs in.

[Ghost0210]

is Boinc asking for CUDA/CPU work or does it think that it has a full cache?
If you have <work_fetch_debug>1</work_fetch_debug> set in your cc_config you should be able to see exactly how much and of what type of work it is requesting when you do an update. I get an output like this:

17/08/2010 10:24:57 |  | [work_fetch] Request work fetch: project updated by user
17/08/2010 10:24:59 | SETI@home | [work_fetch] request: 0.00 sec CPU (0.00 sec, 0.00) NVIDIA GPU (0.00 sec, 0.00) ATI GPU (0.00 sec, 0.00)
17/08/2010 10:24:59 | SETI@home | Sending scheduler request: Requested by user.
17/08/2010 10:24:59 | SETI@home | Reporting 1 completed tasks, not requesting new tasks
17/08/2010 10:25:06 | SETI@home | Scheduler request completed

(have a full 4 day cache at the moment so not requesting any further work)

[Frizz]

is Boinc asking for CUDA/CPU work or does it think that it has a full cache?
If you have <work_fetch_debug>1</work_fetch_debug> set in your cc_config you should be able to see exactly how much and of what type of work it is requesting when you do an update. I get an output like this:

Thanks for this info. I enabled debugging.

This is what I got:

8/17/2010 11:34:21 AM      [wfd] ------- start work fetch state -------
8/17/2010 11:34:21 AM      [wfd] target work buffer: 864.00 + 864000.00 sec
8/17/2010 11:34:21 AM      [wfd] CPU: shortfall 1353069.72 nidle 0.00 saturated 521306.41 busy 84105.23 RS fetchable 100.00 runnable 100.00
8/17/2010 11:34:21 AM   SETI@home   [wfd] CPU: fetch share 1.00 LTD 0.00 backoff dt 0.00 int 0.00
8/17/2010 11:34:21 AM      [wfd] NVIDIA GPU: shortfall 0.00 nidle 0.00 saturated 4914687.81 busy 4421754.51 RS fetchable 100.00 runnable 100.00
8/17/2010 11:34:21 AM   SETI@home   [wfd] NVIDIA GPU: fetch share 1.00 LTD 0.00 backoff dt 0.00 int 0.00
8/17/2010 11:34:21 AM      [wfd] ATI GPU: shortfall 0.00 nidle 0.00 saturated 1040283.39 busy 1040283.39 RS fetchable 100.00 runnable 100.00
8/17/2010 11:34:21 AM   SETI@home   [wfd] ATI GPU: fetch share 1.00 LTD 0.00 backoff dt 0.00 int 0.00
8/17/2010 11:34:21 AM   SETI@home   [wfd] overall LTD -66624275.39
8/17/2010 11:34:21 AM      [wfd] ------- end work fetch state -------
8/17/2010 11:34:21 AM   SETI@home   [wfd] request: 1353069.72 sec CPU (1353069.72 sec, 0.00) NVIDIA GPU (0.00 sec, 0.00) ATI GPU (0.00 sec, 0.00)

[Richard Haselgrove]

These are the important bits:

NVIDIA GPU: shortfall 0.00
ATI GPU: shortfall 0.00

You've got enough for the GPUs - doesn't need any more.

[Frizz]

These are the important bits:

NVIDIA GPU: shortfall 0.00
ATI GPU: shortfall 0.00

You've got enough for the GPUs - doesn't need any more.

I see. This logging would have been interesting last week when I had ZERO tasks for CUDA and ZERO tasks for CPU left - and still had this "not requesting new work" messages in the log.