Please try it out and report problems here.
boinc.

http://boinc.berkeley.edu/dl/

gdf

There is no boinc_6.4.3_windows_x86_64.exe

Linux Only!

Windows versions now posted. (but not tested yet).

Change log:
client: work-fetch tweak: don't increment overall CPU shortfall if any jobs pending in simulation
client: use FLOPs, rather than CPU time, as the basis for estimating job completion times. This should improve estimates for GPU apps, and prevent the DCF from getting messed up.
client: estimate time to completion based on elapsed time, not CPU time (improves estimates for coproc apps)
client: compute duration_correction_factor based on elapsed time, not CPU time (otherwise it doesn't work for coproc or multi-proc apps)
client: in estimate of job completion time, weight the estimate based on fraction done more heavily (quadratic rather than linear)
Remove the notion of "CPU efficiency" from both client and server. This wasn't being measured correctly for coproc/multithread apps, and its effect is now subsumed in DCF.
client: fix calculation of CPU shortfall; don't fetch work from projects with zero CPU shortfall
client: fix compiler warning.
client: parse checkpoint_elapsed_time from state file; if missing, use checkpoint CPU time.
client: enforce CPU schedule: if we're running a coproc job, keep CPU utilization strictly less than NCPUS.
client: fix last checkin

Upgrade was smooth...no problems so far

There's still something odd with the scheduler...

This morning I updated to 6.4.3 on my Vista 64 host. I had no GPUGRID tasks in the queue because I've set GPUGRID unintentionally to no new work last night.

In order to run GPUGRID tasks at full speed I had to set BOINC to use only 3 cores of my Quad, but now I have 3 WCG beta tasks running at high priority, GPUGRID is allowed to fetch new work, but BOINC does not fetch any work from GPUGRID. Now I'm only crunching on three cores and one core is idle...



[edit]
After changing the number of useable processors from three to four, I have still the 3 WCG beta WUs running at high priority, and one Cosmo task is running, but BOINC does not fetch work from GPUGRID.



After suspending all running projects, BOINC fetched some work from GPUGRID, I've set the number of useable CPUs back to 3, and now had only 2 WCG betas at high priority and one GPUGRID task running... So I had to change the CPUs once again to four useable CPUs, and have now three WCG beta tasks plus one GPURID task running, which is actually better now because the GPUGRID task is getting one full core and is using about 14% of one core (25% is the max of one core).

---

pixelicious.at - my little photoblog

I met a problem with it too. On WinXP 64-bit Boinc manager runs only two tasks, one of them is GPUGRID WU, and it takes about 30% of dual-core CPU on average. Unfortunately, I think it's better to rollback to previous version.

Right now I have rolled back to 6.4.2 version. Running OK.

Well, I'll stay with 6.4.3 because it is now with 100% of the CPUs running the same way like with previous versions set to use 75% of the CPUs... Haven't tested Linux though...

---

pixelicious.at - my little photoblog

With this version or the previous, i have the same strange problem.

This morning, when i was monitoring my computers, i saw that on computer with 2 GPU cards, i only had one task running.

I try to update the project, but did'nt receive any new WU.
So i suspend all my project, but don't get any new WU.

And i saw that BOINC said for GPUgrid, "1 deadline misses"! I have only one task ruuning, and the deadline is in 4 days!!!
On another computer, i have WUs waiting to start, and one running. But in Boincview, i see the completion time will be 20 days!!!

So what's happend with the schedule?
Right now, i can't have WUs waiting to run, i have only task running for GPUgrid.

Jim PROFIT

EDIT: On another computer, just after a wu was completing, estimate time was going to 30 days on another computer.

There have been some problems reported if you have any project application that uses an anonymous platform. You get "-1 second" work requests, even for projects not using the anonymous platform if you have any project that uses one.

- client: work-fetch tweak: don't increment overall CPU shortfall
if any jobs pending in simulation
- client: use FLOPs, rather than CPU time,
as the basis for estimating job completion times.
This should improve estimates for GPU apps,
and prevent the DCF from getting messed up.
- client: estimate time to completion based on elapsed time, not CPU time
(improves estimates for coproc apps)
- client: compute duration_correction_factor based on elapsed time, not CPU time
(otherwise it doesn't work for coproc or multi-proc apps)
- client: in estimate of job completion time,
weight the estimate based on fraction done more heavily
(quadratic rather than linear)
- Remove the notion of "CPU efficiency" from both client and server.
This wasn't being measured correctly for coproc/multithread apps,
and its effect is now subsumed in DCF.
- client: fix calculation of CPU shortfall;
don't fetch work from projects with zero CPU shortfall
- client: fix compiler warning.
- client: parse checkpoint_elapsed_time from state file;
if missing, use checkpoint CPU time.
- client: enforce CPU schedule: if we're running a coproc job,
keep CPU utilization strictly less than NCPUS.
- client: fix last checkin

With the change from cpu time to flops counting for the DCF usage, if your old DCF value is way off, you will experience problems until it is reset or self corrects, which takes time.

With these changes, you need to allow the client time to run apps and correct the values. This does not happen instantly, in some cases this could take up to a week or so, it needs time.

Sorry I have not had time to test this version yet.

I'm am busy preparing for an upcoming vacation. I will be quite tied up for the next 10 days with little time to test new clients or help out here, then I will be on vacation for 12 days until after Christmas. Then I have to catch up with work before the end of the year and then we do a complete inventory at work for the new year, so I will quite busy for a while with less time for BOINC'in.

Hi (my first post)

Thought that I would pass this on. I had been running 6.4.1 on 3 cores (Q6600). Changed to 6.4.3 and made 4 cores available. No noticable degradation in GPU performance :-).
I am running Vista premium 64 bit, on an Intel Q6600 (2.4 @ 3.2 GHz) with 4 GB RAM & NVIDIA 8800GT(factory clocked to 700/1840 MHz).
Now running W.C.G on four cores & GPUGRID on NVIDIA 8800GT.

Yeah, when I installed 6.4.3 on my quad running XP, BOINC only started 3 tasks. I then had to changed my preferences to use 100% of my CPUs to get 4 tasks running. This doesn't make sense since the cuda task is rated to use 0.9 CPUs and I had the preference set to use 99% of my CPUs.

Further to my previous message. I have Malaria Control, GPUGRID and Milkyway as projects on my quad. With my actions in my previous post I had 4 tasks running, 3 Malaria Control and 1 GPUGRID. During this time Milkyway was trying to download some work and was having difficulty. Once Milkyway finished downloading a Milkyway task started, leaving 5 tasks running.

[update] I changed the cpu usage preference to 99% and it went back to running 4 tasks. I then shut BOINC down and restarted and now only 3 tasks are running. I'll see what happens once the next tasks finishes.

[update 2] As I suspected, once a task completed it went to running 4 tasks.

I think that BOINC has reverted the default behavior to leave 1 CPU free for the GPU, but I might be wrong.

gdf

Yeah, when I installed 6.4.3 on my quad running XP, BOINC only started 3 tasks. I then had to changed my preferences to use 100% of my CPUs to get 4 tasks running. This doesn't make sense since the cuda task is rated to use 0.9 CPUs and I had the preference set to use 99% of my CPUs.

It doesn't work that way.

The CPU% is changed to physical cores, minimum of 1, without going over.

So far a quad core, 1%to49%=1, 50%-74%=2, 75%-99%=3 and 100%=4 cores.

---
I tried an upgrade.

There does seem to be a flaw (or change ?) in the 6.4.3 logic.

I had same problem. With my P4-HT (two cpu threads) and 6.4.2 with cpu usage set to 50% I got 1 CPU plus 1 CUDA/CPU-0.90 running.
When upgrading to 6.4.3 I did not, Only the 1 GPU task. I had to up the cpu usage to 100% to get the previous amount running.

I've reported these findings to see what the answer is. Being the week-end though it may take a while for an answer.

I downgraded to 6.4.2 while my PCs are running dry under 6.4.3. The other problems with 99% CPU using and 100% using are the same are detailed told here. I could live with, but not with no new work. The BOINC manager called 0 seconds, also with 0 WU for work.

After downgrade the WU length is shown with over 700 hours and no second WU is loading. Have to wait till the rest of time decrease ...

---

Would a project reset reset the counters to reasonable values?

MrS

---

Scanning for our furry friends since Jan 2002

I'm told the behavior in 6.4.3 is correct.

It has been changed because the goal is to have GPU jobs run at top speed without people having to change their #CPUs preference. So if there is a GPU job running, the scheduler will avoid saturating the available CPU's (otherwise the GPU job runs slow).

Would a project reset reset the counters to reasonable values?

MrS

No, I've changed the duration_correction_factor back to 1 from over 100. After this editing I got new WUs.

---