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.

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

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

- 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,

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.

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.

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.

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!

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.