BOINC 6.6.20 released for Windows, Windows x64, and MacOS X

Rom Walton wrote:

Howdy Folks,

We are pleased to announce the first of the 6.6 clients to be ready for
public consumption.

This release includes:

1. A new CPU/GPU scheduler.

2. An improved work-fetch policy.

3. Improved communication handling between the manager and client
software.

4. Consolidation between the grid based advanced view and the list based advanced view for accessibility improvements.

Future 6.6 releases will include the updated localization files that the localizers have been hard at work on.

We would like to thank all the testers for their hard work over the last few months, without your help we would not have had as stable a client as we have now.

----- Rom

Warning:
When you change over from 6.4.x and you run a cc_config.xml file with the <ncpus>CPUs+1</ncpus> option, you will have to remove this option or delete the cc_config.xml file and restart BOINC. The new GPU scheduler in this new BOINC will take care of this.

http://boinc.berkeley.edu/download.php

---

*** WARNING ***

In the course of testing BOINCs v6.6.14/15/16 for compatibility with optimised applications, Lunatics uncovered the cause of the unexpectedly high number of reports of 'High Priority' running with CUDA/optimised applications. The bug in BOINC has been corrected in v6.6.20 and you should see less 'High Priority' from now on.

BUT: this early 'High Priority' is one of the reasons why large cache requests have very rarely been filled in the past. Once any SETI task (AP, MB, or CUDA) goes into High Priority, no further work will be requested.

Until now.

With BOINC v6.6.20, you are much more likely to get what you ask for. And that may be much more than you are expecting.

In the early days of running BOINC v6.6.20, I strongly advise that you turn down your requested cache size, especially on fast multi-cpu, multi-gpu rigs, to no more than one or two days: then turn it back up gradually, allowing work fetch to complete between each change.

There is a secondary problem, which has only just come to light. In BOINC v6.6.20, CUDA tasks always run in "earliest deadline first" (EDF) mode, whether or not they are also running 'High Priority'. If a new CUDA task is downloaded with an earlier deadline than the currently-running CUDA task, the old one will be preempted and the new one will take its place.

Sometimes BOINC is too impatient in doing this, and starts the new task before the old one has finished tidying up after itself. Result: too much graphics memory is allocated, the new CUDA task reports a malloc error, and runs - very slowly - in CPU fallback mode. So, if your upgrade to v6.6.20 triggers a large cache fetch, monitor the next few CUDA tasks and check they're running at normal speed. If they seem to be running slow, and using 100% CPU according to Task Manager, my advice would be to reboot the computer.

[This seems particularly likely just at the moment - Murphy's Law strikes again - because I'm seeing a wide variation of Angle Range and hence deadline in tasks I've downloaded today. VLAR, VHAR, and everything in between. I find my 512MB CUDA cards gag if they are asked to preempt two tasks at once: there's space for a running task and a preempted task in memory, but a third task pushes them over the edge into the malloc error. David Anderson has said that he will try and re-code this part of BOINC next week, so watch out for references to test versions of BOINC v6.6.22 and above]

The bug in BOINC has been corrected in v6.6.20 and you should see less 'High Priority' from now on.

I have 6.6.20, and am still seeing 'High Priority', but that is on the AP WU. Is this supposed to be fixed for AP WU with 6.6.20, or is there going to be a later release to address it?

---

Under normal circumstances 'High Priority' is not something that needs to be fixed. This is a safety mechanism for when BOINC thinks your task isn't going to make deadline. It will focus on that one task running it in 'High Priority', trying to get it in before the deadline anyway. In the mean time it won't get any new work to crunch, while that one CPU doing the AP task won't switch to any other work at the end of the "switch application interval' you set. Not until BOINC is reasonably sure that it can bring the task in in time.

Putting it into the context of the thread and forum you posted this in, it was a problem with CUDA, as older BOINC versions would run all CUDA tasks in this high priority mode, not allowing BOINC to switch between CUDA tasks.

---

Under normal circumstances 'High Priority' is not something that needs to be fixed. This is a safety mechanism for when BOINC thinks your task isn't going to make deadline. It will focus on that one task running it in 'High Priority', trying to get it in before the deadline anyway. In the mean time it won't get any new work to crunch, while that one CPU doing the AP task won't switch to any other work at the end of the "switch application interval' you set. Not until BOINC is reasonably sure that it can bring the task in in time.

Putting it into the context of the thread and forum you posted this in, it was a problem with CUDA, as older BOINC versions would run all CUDA tasks in this high priority mode, not allowing BOINC to switch between CUDA tasks.

Please excuse the somewhat off-topic post, but this is where I found the note that the 'High Priority Bug' had been fixed in 6.6.20.

I understand that you are saying that "High Priority" = "Don't preempt this task, and don't download any more tasks until this one is done".

It is just the second part that bothers me since I only run one project (S@H).

The fact is that the AP tasks always run in this mode because BOINC is pretty much always over-estimating the duration_correction_factor, resulting in all AP tasks being estimated to take way more time than they actually take.

I have calculated a more accurate DCF for my cuda-capable host, and I have written a script to edit the client_state.xml, put in the "correct" value, then restart BOINC.

For a while after this script is run, the AP tasks will be run without the 'High Priority' tag... at least until the DCF is again calculated by BOINC... and BOINC will usually fetch a bunch of new tasks.

---

I just upgraded to 6.6.20 and it does not look like SETI is downloading WUs anymore. I run SETI on the GPU. World Community Grid is still downloading new units but I get the following message when I try to update.

4/25/2009 5:44:36 PM SETI@home Sending scheduler request: Requested by user.
4/25/2009 5:44:36 PM SETI@home Not reporting or requesting tasks
4/25/2009 5:44:41 PM SETI@home Scheduler request completed: got 0 new tasks

I am down to a half a dozen WU in the queue and before I use to have dozens.

- Mitch

---

v6.6.20 has fixed scheduler problems that existed in prior versions of BOINC. v6.6.20 is more conservative with your cache settings in order to properly maintain deadlines. Once v6.6.20 cleans up the mess left behind by prior versions of BOINC, things will go back to normal (or at least the way they should have been).

---

BOINC 6.6.20 released for Windows, Windows x64, and MacOS X


Warning:
When you change over from 6.4.x and you run a cc_config.xml file with the <ncpus>CPUs+1</ncpus> option, you will have to remove this option or delete the cc_config.xml file and restart BOINC. The new GPU scheduler in this new BOINC will take care of this.

http://boinc.berkeley.edu/download.php

I have done this and now I only appear to be running 3 cpu and 1 gpu jobs, is it not possible to use all 4 cores plus the gpu on a quad core machine?

---

Bambi

After much forum searching and studying of my app_info.xml file I fixed things.
I am now happily running 4 cpu jobs and 1 cuda job....

9/10 its user error.....

---

Bambi