On fresh installed system BOINC was able to detect OpenCL devices and properly detected CPU as being 4 cores.
But it runs only 2 tasks. One for OpenCL GPU and another one for CPU.
Why not 4 for CPU (task is SETI beta one so not really multithreaded one)?
How to make it run 4 CPU tasks on 4 cores?

EDIT: after few minutes it picked up another 3 tasks... but why delay? Transfers tab was empty while it ran only 1 CPU tasks and tasks tab showed numerous tasks available...

---

On project initialisation, the project generally only sends one task for each device, you'll get more once the project backoff ends, as you're discovered.

http://setiweb.ssl.berkeley.edu/beta/show_host_detail.php?hostid=75216

24 May 2015, 8:57:27 UTC. Picked up single SETI@home v7 v7.00 task and single SETI@home v7 v7.06 (opencl_ati5_cat132) task.

24 May 2015, 8:57:40. UTC Picked up 40 SETI@home v7 v7.06 (opencl_ati_cat132) tasks, But no CPU tasks, this would have put Boinc into CPU backoff.

24 May 2015, 9:03:29 UTC. Picked up 31 SETI@home v7 v7.00 tasks and 9 SETI@home v7 v7.06 (opencl_ati5_cat132) tasks.

24 May 2015, 9:03:41 UTC. Picked up 18 SETI@home v7 v7.00 tasks.

Claggy

What does the Event Log say about scheduler work requests?

The design behaviour for a freshly installed system (after attaching to a project) is to request 1 second of work for each of the available compute device types - so that's one second of work for CPUs collectively (not 'per CPU'), 1 second for NVidia GPU (if discovered), one second for AMD GPU (ditto), one second for Intel GPU (ditto), and so on.

Those one-second requests will, at most projects, result in one task being allocated for each and every device. The project initialisation will also result in user preferences (such as number of CPUs allowed to run concurrently), application speed and task size estimates, etc. etc. being transferred to the new host. Once all this information is available, additional work requests will be issued to utilise any idle resources. At projects like SETI, the 5-minute backoff between scheduler contacts can slow this process down, but the 7-second backoff at Beta should be insignificant.

If your report is saying that

* multiple CPU tasks have been allocated
* all application downloads have completed
* all task data downloads have completed
* active preferences allow all CPUs to be used
* no other preference is inhibiting BOINC resource usage (check 'suspend BOINC when non-BOINC CPU usage is above ...', for example)

and there is still an appreciable delay (more than a minute) between tasks being 'Ready to start' and actually starting, then your best bet is to send the event log to boinc_alpha.

Otherwise, I think that measured, step-by-step, initialisation procedure is appropriate for 99.999% of users and new computers.

Thanks for answers.
I think Claggy's described scenario was realized: BOINC client (not project) backoff on CPU task request. That stealed ~12 mins of CPU time for project.

Usually those client self-induced backoffs hurt only GPU tasks allocation on SETI (if you want AstroPulse then prepare clicker for update button).

---