Slight "Gripe:" In Server Status I cannot determine whether or not GPU tasks are available. Once downloading, it is clear which task is configured for GPU(s).

---

Quite simple - all tasks start out the same, at download time they are ASSIGNED to either a CPU or GPU.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Quite simple - all tasks start out the same, at download time they are ASSIGNED to either a CPU or GPU.

You know, I always hear that said, and I'm not disputing it, but it doesn't correspond to what I regularly see:

... Requesting new tasks for CPU and NVIDIA GPU
... Scheduler request completed: got 0 new tasks
... No tasks sent
... No tasks are available for SETI@home v7
... No tasks are available for AstroPulse v7
... Tasks for AMD/ATI GPU are available, but your preferences are set to not accept them
... Tasks for Intel GPU are available, but your preferences are set to not accept them

So here the implication is that SETI@home v8 tasks are available, but only for AMD and Intel, but not for NVidia or CPU.

---

So here the implication is that SETI@home v8 tasks are available, but only for AMD and Intel, but not for NVidia or CPU.

It's poor wording/logic from the Scheduler.

... Tasks for AMD/ATI GPU are available, but your preferences are set to not accept them
... Tasks for Intel GPU are available, but your preferences are set to not accept them

If you've reached the server-side limits, those messages are usually followed by
... This computer has reached a limit on tasks in progress

so even if you had asked for AMD/ATI or Intel GPU work, you wouldn't have got any.


15/02/2016 18:15:34 | SETI@home | Sending scheduler request: To fetch work.
15/02/2016 18:15:34 | SETI@home | Requesting new tasks for CPU and NVIDIA GPU
15/02/2016 18:15:37 | SETI@home | Scheduler request completed: got 0 new tasks
15/02/2016 18:15:37 | SETI@home | No tasks sent
15/02/2016 18:15:37 | SETI@home | No tasks are available for SETI@home v7
15/02/2016 18:15:37 | SETI@home | No tasks are available for SETI@home v8
15/02/2016 18:15:37 | SETI@home | Tasks for AMD/ATI GPU are available, but your preferences are set to not accept them
15/02/2016 18:15:37 | SETI@home | Tasks for Intel GPU are available, but your preferences are set to not accept them
15/02/2016 18:15:37 | SETI@home | This computer has reached a limit on tasks in progress

and that is also the response you generally get when requesting NVidia GPU work, and only VLAR work is available.


There is work available, but for whatever reason (server-side limits, VLARs on a NVidia GPU work request) you can't have any.

---

Grant
Darwin NT

It's poor wording/logic from the Scheduler.

Agreed. Basically, the results are being presented in the wrong order.

and that is also the response you generally get when requesting NVidia GPU work, and only VLAR work is available. There is work available, but for whatever reason (server-side limits, VLARs on a NVidia GPU work request) you can't have any.

And still inconsistent, in that if the reason is because it was for VLARs, the CPU should still have gotten work because

This computer has reached a limit on tasks in progress

was not presented and limits were not exceeded (e.g. number of tasks [100] nor days of work) for either CPU or GPU.
That case I can duplicate consistently, on each of three crunchers. I get the logic, and how it should all flow, as it's really a pretty straight-forward logic tree given the variables. Not all that complicated.

---

This code was written in 2010, and has operated the same way ever since then.

Date: 12/07/2010 23:43:53
Message:
- scheduler: add a clause to wu_is_infeasible_custom() for SETI@home:
don't process VLAR jobs using CUDA apps.
Note: this is implemented in a slightly non-optimal way.
If the request asks for both GPU and CPU jobs,
the scheduler will first decide to use the GPU version.
It will scan jobs, skipping over VLAR jobs.
When the GPU request is satisfied, it will switch to the CPU version
and continue scanning, accepting VLAR jobs.
But the jobs that were skipped initially won't be rescanned.
Also, it would be slightly nice to preferentially send
VLAR jobs to hosts asking for CPU work.
(This could be done in the scoring function).

Basically, it works well enough from the project's point of view, and the various small glitches sort themselves out well enough not to be worth spending scarce programming time on. If anyone can submit alternative, working, code to do it better, you have a fair chance of getting it accepted - but remember, the phrase "if it ain't broke, don't fix it" was coined for a reason.

Now, we'd better move this discussion out of the 'Gripes and Kudos' thread.

When the GPU request is satisfied, it will switch to the CPU version
and continue scanning, accepting VLAR jobs.
But the jobs that were skipped initially won't be rescanned.

That sounds like why (for AP) downloads, my GPU cache has to be full before I get CPU tasks.