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

Questions and Answers : GPU applications : BOINC 6.6.20 released for Windows, Windows x64, Linux, Linux x64 and MacOS X
Message board moderation

To post messages, you must log in.

AuthorMessage
Profile Jord
Volunteer tester
Avatar

Send message
Joined: 9 Jun 99
Posts: 15184
Credit: 4,362,181
RAC: 3
Netherlands
Message 883738 - Posted: 9 Apr 2009, 18:12:35 UTC

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
ID: 883738 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14659
Credit: 200,643,578
RAC: 874
United Kingdom
Message 883968 - Posted: 10 Apr 2009, 16:13:25 UTC

*** 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]
ID: 883968 · Report as offensive
Profile Steven Meyer
Avatar

Send message
Joined: 24 Mar 08
Posts: 2333
Credit: 3,428,296
RAC: 0
United States
Message 885495 - Posted: 15 Apr 2009, 8:29:28 UTC - in response to Message 883968.  

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?
ID: 885495 · Report as offensive
Profile Jord
Volunteer tester
Avatar

Send message
Joined: 9 Jun 99
Posts: 15184
Credit: 4,362,181
RAC: 3
Netherlands
Message 885504 - Posted: 15 Apr 2009, 8:50:55 UTC - in response to Message 885495.  

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.
ID: 885504 · Report as offensive
Profile Steven Meyer
Avatar

Send message
Joined: 24 Mar 08
Posts: 2333
Credit: 3,428,296
RAC: 0
United States
Message 888041 - Posted: 24 Apr 2009, 21:35:39 UTC - in response to Message 885504.  

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.

ID: 888041 · Report as offensive
mclaver

Send message
Joined: 1 Nov 01
Posts: 11
Credit: 142,239,750
RAC: 113
United States
Message 888358 - Posted: 25 Apr 2009, 22:50:58 UTC

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
ID: 888358 · Report as offensive
OzzFan Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 9 Apr 02
Posts: 15691
Credit: 84,761,841
RAC: 28
United States
Message 888892 - Posted: 27 Apr 2009, 20:38:06 UTC - in response to Message 888358.  

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).
ID: 888892 · Report as offensive
Profile Bambi

Send message
Joined: 15 May 99
Posts: 26
Credit: 5,704,701
RAC: 1
United Kingdom
Message 888915 - Posted: 27 Apr 2009, 21:54:03 UTC - in response to Message 883738.  

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

ID: 888915 · Report as offensive
Profile Bambi

Send message
Joined: 15 May 99
Posts: 26
Credit: 5,704,701
RAC: 1
United Kingdom
Message 889198 - Posted: 28 Apr 2009, 15:32:58 UTC - in response to Message 888915.  

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

ID: 889198 · Report as offensive

Questions and Answers : GPU applications : BOINC 6.6.20 released for Windows, Windows x64, Linux, Linux x64 and MacOS X


 
©2024 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.