Seeing as there are a fair few changes since 6.10.37 I decided it better get its own message thread. Currently its only available for Linux and Windows. To quote Rom...

This release changes some UI elements in the Manager and increases the efficiency in both the client and the manager. This release also fixes some CPU/GPU scheduler issues. People with large machines and large caches should notice a reduction in CPU utilization in the CC and Manager when they are both up and running.

REMINDER TO ALL TESTERS:
It's far easier for us to fix problems if you send message logs with the appropriate flags set. The main flags are:

<cpu_sched_debug>: problems involving the choice of applications to run.
<work_fetch_debug>: problems involving work fetch (which projects are asked for work, and how much).
<rr_simulation>: problems involving jobs being run in high-priority mode.

Use these flags from the cc_config.xml file.

Report any problems you get with it to the Alpha email list. This list needs registration.

And the change log since 6.10.37...

6.10.37/38:
- MGR: Save & restore size information of properties dialogs separately for project and task property dialogs, also save and restore dialog positions on Mac.

- Mac: explicitly specify compiler as GCC 4.0 instead of system default in build settings to allow building with XCode 3.2 on OS 10.6 as well as XCode 3.1 on OS 10.5.8.

- MGR: Instead of alternating gray and white backgrounds in lists, create CBOINCListCtrl with wxLC_HRULES flag. This avoids theme color conflicts with our backgrounds. It also eliminates the need to set item attributes, since the default attribute setting already uses theme colors.

- MGR: Remove some hacks to deal with early wxGTK bugs which have since been fixed.

- MGR: Restore wxGTK hacks, bug is still alive and well.

- client: revisit the domino-effect preemption problem. Removed my changes of 19 Jan 2010, which didn't work. Added new mechanism: keep track of whether a job J has ever run in EDF. If so, and if another job of the same project and resource type as J is marked as deadline miss, then mark J as deadline miss, so that it won't get preempted.

- client: if a GPU job is blocked on available mem, don't fetch more jobs for that resource type

- MGR: Improve performance when reducing number of rows in lists (as when selecting "Show active tasks") by calling ClearSelections() and SetItemCount() instead of repeatedly calling DeleteItem().

- MGR: Fix a bug which caused unnecessary demand RPCs on some platforms: set RPC time stamps to 1 rather than 0 in RefreshRPCs() so a not to trigger initialization code.

- client: don't suspend non-CPU-intensive jobs because of CPU load

- MGR: Prevent flicker and lack of display by using the regular tooltip for the Project List control on Windows.

- client: if suspending apps because of CPU benchmarks, leave them in memory

- MGR: Fix to my previous checkin: RefreshRPCs() shouldn't change time stamp if it was zero, as this is a special vslue to indicate the RPC has never been called.

- Remove BOINC_RCSID tags from source files, we are doing branching and tagging properly.

- client: add missing CPU scheduler code

- client: fix formatting in app_control.cpp

- MGR: fix build break

- Mac Sandbox: Fix bug in my changes of 26 Jan 2010 to set projects directory and slots directory to group boinc_project, not boinc_master.

- client: in computing non-BOINC CPU time, exclude any process whose executable includes "boinc", case-insensitive.

- Fix problem with BoincTasks.exe

NOTE: this affects only Win and Linux; Mac already had case-insensitive comparison.


6.10.39:
- fix bugs in strcasestr(), which apparently had never been tested

- Define HAVE_ALLOCA in boinc_win.h so that any component using strcasestr in str_util.cpp uses stack allocations instead of more expensive heap allocations.

- Move remaining HAVE_* defines from project files to boinc_win.h


6.10.40:
- MGR: Allow separate compile-time choice of rules and / or alternating gray and white background stripes in lists by defining BASEVIEW_RULES and BASEVIEW_STRIPES (in BOINCBaseView.h); set each to 1 to enable or 0 to disable; currently both are set to 1 for both stripes and rules.

- MGR: Change previous commit to strips only for the next build. Things look wonky with both stripes and rules around the margins.

- client (and anything else using MFILE): Win efficiency fix. Shockingly, realloc() wasn't doing exponential growth. So create realloc_aux() that does.


6.10.41:
- unix compile fix

- MGR: Derive messages tab colors from base class colors.


6.10.42:
- MGR: Switch background color for the list view stripes back to the original color (247, 247, 247).


6.10.43:
- MGR: Deconflict menu IDs

---

BOINC blog

- client: if a GPU job is blocked on available mem, don't fetch more jobs for that resource type

What do you mean by "GPU job is blocked on available mem"?

...blocked because there is not enough memory?
...locked to memory areas?

Stopping further GPU allocation could be an issue here if there are several different tasks requiring different memory amounts, if thats what you meant.

Thanks,

- client: if a GPU job is blocked on available mem, don't fetch more jobs for that resource type

What do you mean by "GPU job is blocked on available mem"?

...blocked because there is not enough memory?
...locked to memory areas?

Stopping further GPU allocation could be an issue here if there are several different tasks requiring different memory amounts, if thats what you meant.

Thanks,

The change log is quoted as its from one of the BOINC developers, not me, What Rom means by that is that it will not request any further work if the GPU doesn't have enough free ram when it tries to start a task.

Recent versions of BOINC checked if there is enough free vram and wait a while before retrying the task. Older versions (ie the 6.2.x) wouldn't even do this and the task simply crashed if it couldn't get the vram it needed. This normally affects the lower-end cards with 256Mb or 384Mb. Most science apps use around 256Mb. Cards with 512Mb (or better) don't run out of vram as often.

---

BOINC blog

Thanks,

So my take on it is, if a card with 256MB RAM does not have enough RAM to run a GPUGrid task (possibly because it is doing other work) it will not get any new tasks while the first task cannot run, but the task will keep trying to run periodically and should it start then another task can be queued.

How long will the task keep trying to run (5days)?

Can GPUGrid identify cards that inherently do not have enough RAM to run certain tasks and prevent them from getting these tasks?

I see an issue for cards with relatively high shader to RAM count (such as the 8800GT 256). In my experience GPUGrid+system uses about 300MB RAM leaving these cards short. Basically all applications would need to be closed and the display would have to be off before the card could crunch again.

MarkJ,

I'm not it's a right place for feature request, but I wonder if there is a chance to implement some kind of "Project's priority management".

Example: I'm crunching for project A and project B using GPU. My priority is project A, but if project A is down or whatsoever, project B starts to work. When project A up again, BOINC switches back to project A.

---

MarkJ,

I'm not it's a right place for feature request, but I wonder if there is a chance to implement some kind of "Project's priority management".

Example: I'm crunching for project A and project B using GPU. My priority is project A, but if project A is down or whatsoever, project B starts to work. When project A up again, BOINC switches back to project A.

Its called a backup project and was in around 6.10.37. See the other BOINC message thread for details. Basically you set your resource share on the backup project to zero and then it knows to only do it when it doesn't have any other work.

---

BOINC blog

Thanks,

So my take on it is, if a card with 256MB RAM does not have enough RAM to run a GPUGrid task (possibly because it is doing other work) it will not get any new tasks while the first task cannot run, but the task will keep trying to run periodically and should it start then another task can be queued.

How long will the task keep trying to run (5days)?

Can GPUGrid identify cards that inherently do not have enough RAM to run certain tasks and prevent them from getting these tasks?

I see an issue for cards with relatively high shader to RAM count (such as the 8800GT 256). In my experience GPUGrid+system uses about 300MB RAM leaving these cards short. Basically all applications would need to be closed and the display would have to be off before the card could crunch again.

I believe that it simply retries the task every 5 or 10 minutes. The task will eventually pass its deadline if it doesn't get to run and will be deleted.

---

BOINC blog

Its called a backup project and was in around 6.10.37. See the other BOINC message thread for details. Basically you set your resource share on the backup project to zero and then it knows to only do it when it doesn't have any other work.

Really? That'd be sooo helpful! Let's adjust that Collatz ressource share.. :D
Edit: uhm, no.. the server does not yet accept a setting of 0.

MrS

---

Scanning for our furry friends since Jan 2002

Its called a backup project and was in around 6.10.37. See the other BOINC message thread for details. Basically you set your resource share on the backup project to zero and then it knows to only do it when it doesn't have any other work.

Really? That'd be sooo helpful! Let's adjust that Collatz ressource share.. :D
Edit: uhm, no.. the server does not yet accept a setting of 0.

The project has to update their server software for it to work. You'll know it's updated when it accepts that 0 priority.

Its called a backup project and was in around 6.10.37. See the other BOINC message thread for details. Basically you set your resource share on the backup project to zero and then it knows to only do it when it doesn't have any other work.

Thx a lot, MarkJ :-) That's what I'm looking for :-)

ExtraTerrestrial Apes,

Boy, you can read in mind :-) last week MW facing server issues and I lost a lot of hours of crunching. I wanna be prepared for next time...

yep, 0 is not working. But I tried 0.00001 and collatz accepts it. I'll get 6.10.43 and let's see :-)

---

I wonder how many people read this, set MW to 0, clicked apply and did not notice that it automatically reset to 100 becasue you cant select Zero?
Do you think it benefits MW/Collatz by allowing Zero? I dont.
Do you think they are going to do it any time soon? Not likely.

You can however use 0.000001 on MW, as well as on Collatz. (1.0E-6)
Using Boinc 6.10.43 wont make any difference to someones web site!

I have two projects set on 0 without server-update: Einstein and QMC. I set the resource-share via BAM on zero and synchronized it with my BOINC-manager. It works for now I think three weeks without any problems.

Its now the official version for Windows and 6.10.44 for Linux and the Mac.

---

BOINC blog

6.10.45 released for Windows and Linux.

The unofficial change log...

- Mac: Update build instructions to replace dead link for downloading JPEG 6b sources.

- Mac: Build with c-ares 1.6.0 instead of c-ares 1.7.0, because the newer c-ares has problems resolving host names on OS 10.6 with default settings when used with AT&T U-Verse 2Wire gateway routers and Airport.

- Manager: fix bug in task properties app name display.

- client/manager: show "No CPU prefs" etc. in project properties.

- client/manager/GUI RPC: project_info.xml file can contain <team_name>. If present, and a new user account is created, it will be made a member of that team if it exists.

- MGR: Bad things happen when you don't initialize default values for variables under wxWidgets.

- client: NVIDIA peak FLOPS estimate was wrong for Fermi (32 cores, not 8).

- client: delete project_init.xml if attached to any project.

- manager: avoid divide by zero if the only project has zero resource share.

- client: Fermi compute capability is 2, not 3.

- client: give dynamic estimate (based on fraction done) a greater weight in time-to-completion estimate.

- Client: fix bug that caused wrong jobs to be run EDF (needed to initialize a var inside loop, not outside).

- client: clean out project dir on reset. Fixes #978

- client: read_file_malloc() must open file in binary mode, else it won't get the right part of the file.

---

BOINC blog

"skgiven" wrote:

How to report tasks immediately:
....
Cache Levels (Additional Work Buffer):
For GPUGRID it is better to set a low cache level of say 0.05days (rather than use the default 0.25days).
Open Boinc in Advanced View, Click Advanced, Preferences, under the network usage Tab set the additional work buffer to a low value.
- This will optimise Work Unit turn around and expedite the project. It will also allow you to collect larger bonuses.

If conntected to more GPU projects (I am connected to Seti & SetiBeta, RS of these 3 projects is the same) it doesn't work even if Seti & SetiBeta projects are suspended. Any LTD bug in 6.10.43 version is present, that leaves GPU idle for a lot of hours. I noticed, that cc_config feature <zero_debts> correct that issue, if core restarted once a week. Unfortunately boinccmd --set_debts command works only for CPU debt.