New build:
http://boinc.berkeley.edu/dl/?C=M;O=D

I dunno what they changes are, but I'm sure someone will come along with them ;)

From an email I received earlier today about what is new in 6.4.2.

Here is a new build to test. This build contains to fixes.



1. A work-fetch fix for GPU related issues.
2. A new ‘Terms of Use’ wizard page for a new up and coming project.
3. A diagnostics fix for crashing bugs.

----- Rom



Change Log:

- Mac: Fix XCode project to build old Manager with Grid Views;

rename SetVersion.C to SetVersion.cpp.

- client: in round-robin simulation, only increment CPU shortfall

(per-project or overall) if there are no pending tasks.

This is needed when there are coproc (i.e. CUDA) jobs;

CPUs may be idle because pending jobs are waiting for active jobs

to release coprocs.

In this situation the CPU idleness should not be counted as shortfall;

otherwise (if there are only coproc jobs) there will always be a shortfall,

and the client will fetch infinite work.

- DIAG: On Windows move the symbol store directory under the

BOINC data directory structure. Depending on the version

of Windows, sometimes the temp directory was being set

to the system temp directory which is not setup for

everyone to use. It is just best to use out data

directory structure.

- GUI RPC: add optional terms_of_use field to project config.

If present, the manager will display this text in a yes/no dialog

before attachment continues.

- MGR: Make the error message processing work for the

get_project_config rpc, use the same scheme as

the ACCOUNT_OUT structure.

- MGR: Make the error message processing work for the

get_project_config rpc, use the same scheme as

the ACCOUNT_OUT structure. I missed the Account

Manager scenario in the first checkin.

- client, Win: 32-bit client running on a 64-bit machine

should report winx64 as primary platform

- MGR: Remove the Account Key page from the Wizard.

- MGR: Add a Terms of Use page to the Wizard.

- MGR: Make the Terms of Use text control read-only

- MGR: fix exit dialog so that both the Mac and Linux clients don't

display the 'close core client...' checkbox.

- WININSTALL: Change the default to not use protected application

install.

- WININSTALL: Change the advanced install text to point out

that on Windows Vista CUDA applications won't work with

protected application installs.

---

Crunching for the benefit of humanity and in memory of my dad and other family members.

If you upgrade, your current task (GPUgrid) might be in limbo as it did on 2 of my rigs. The rest of my rigs, i suspend first the gpugrid before upgrading then resume after the benchmark - works well by doing this.

If this works well, we will suggest this release version.
Please report.

gdf

If this works well, we will suggest this release version.
Please report.

gdf

Testing is underway.

Looks good and the Accessible View is back, only some refresh bugs in tabs, reported at boinc alpha.

If this works well, we will suggest this release version.
Please report.

gdf

You should wait for 6.4.3. More small fixes/enhancements have been implemeted since 6.4.2 was released. They are working toward the goal of smoothing out work load, no more too few or too many for either cpu's or gpu's. Once a majority of users upgrade you can remove the X per cpu limit you now have set, which doens't work well for all users here. There already should be a new gpu limit in the server software. The client should better handle getting the correct number of tasks per gpu per computer and also adjust as with cpu jobs for the time (counted in flops) the gpu portion taks and not overload slower gpu's with work that cannot be finised by deadline. Faster gpu's will of course get more work on standby depending on queue size if it can be estiamted to be completed within deadline. You probably should also consider lowereing the 0.90 cpu use number to a more realistic numebr. I don't know if you can have separate for each o/s so use 0.35 which is around the windows usage. IF you can ahve separate then use the 0.02 for linux and 0.35 for windows. That way suers with multiple gpus will have a more closer cpu per gpu usage for the part boinc does the computations for.

and 0.35 for windows

If I give my GPU a dedicated core the usage is just below 20% of my Q6600@3GHz on average, which amounts to 80% of a core. Using the maximum number of cpu tasks drops this value to something between 15 and 20%. So 35% is not a general value.. and neither do I expect my 80% to be.

MrS

---

Scanning for our furry friends since Jan 2002

and 0.35 for windows

If I give my GPU a dedicated core the usage is just below 20% of my Q6600@3GHz on average, which amounts to 80% of a core. Using the maximum number of cpu tasks drops this value to something between 15 and 20%. So 35% is not a general value.. and neither do I expect my 80% to be.

MrS

Actually your right. The 35 is what one half of my HT CPU uses (more like 30-40 so I just picked a number in the middle, where 50 is the max, so it is more like 80% of a core and not the entire CPU.

It's been a long work day, my brain is fried.

If I give my GPU a dedicated core the usage is just below 20% of my Q6600@3GHz on average, which amounts to 80% of a core. Using the maximum number of cpu tasks drops this value to something between 15 and 20%. So 35% is not a general value.. and neither do I expect my 80% to be.

MrS

On my GTX 260/Q9300 the acemd task needs about 14% CPU which would be 56% of one core if I run only three CPU tasks...

I already reported that on the BOINC alpha mailing list some weeks ago before they meant that it is time to drop 6.3 and switch to 6.4 to bring out a CUDA BOINC client, but got ignored by the devs. The only answer I got was from JM7 -

I'm a bit surprised that it is taking 60% of a CPU if there is a CPU that is completely free and only 10% of the CPU if there is a CPU intensive task running as I thought that the priority of the CPU portion of the GPU task was run at higher poriority than the CPU intensive tasks.

...

In fact it is running with higher priority, but still it doesn't get the CPU it would need...
But I don't see much sense anymore to report such things to BOINC alpha if you don't get an answer from the devs. Not a single question, no "we are looking into the problem". Nothing... :-/ I would have thought that this is an important thing if they want a working CUDA BOINC client. And they are really wondering why there are only so few alpha testers?!

---

pixelicious.at - my little photoblog

I can imagine they're busy with other stuff and regard this as a temporary issue, because it could change anytime the GPU client changes. Or they've got plenty of time until another GPU project appears and it's generally an issue of the specific app and the win scheduler, not so much BOINC. BOINC does start the GPU-task with higher priority.. what else could BOINC do anyway? An answer would be nice, though!

In fact it is running with higher priority, but still it doesn't get the CPU it would need...

Agreed, at least under win.

MrS

---

Scanning for our furry friends since Jan 2002