The following fixes are included in this BOINC client software version released earlier today for testing...

Mac client: fix bug in build script so that curl-7.19.2 actually

does build with c-ares 1.6.0. Fixes #830. (Checked into

boinc_core_release_6_6_2 tag and boinc_core_release_6_6a branch.)

- client: fix messages

- client: fetch work from non-CPU-intensive projects

- client: compile fix, remove spurious message

- MGR: Make sure the UI thread doesn't call a GUI RPC

that uses the SET_LOCALE class.

- MGR: fix compile error.

- client: if an app has avg_ncpus < 1, run it at above-idle priority

even if it doesn't use a coprocessor.

- scheduler: added an "nci" (non CPU intensive) plan class

to sched_plan.cpp. It declares the use of 1% of a CPU.



The above two changes are intended to allow the QCN app to

run at above_idle priority, which it needs in order to do 500Hz polling.



- API: the std::string version of boinc_resolve_filename()

acts the same as the char[] version.

- client sandbox: add details in switcher_exec "execv failed" message.

- MGR: Work around bug in generic list control GetSelectedItemCount()

which caused incorrect update of buttons in Projects tab after

detching from a project; remove redundant UpdateSelection() call.

- MGR: Remove override of GetSelectedItemCount() introduced yesterday;

instead, call DeleteItem() rather than SetItemCount() when number of

rows has been reduced, to allow virtual ListCtrl adjust its list of

selected rows (and thus keep its count in sync with reality.)

- MGR: Don't use wxT() to describe parameters passed to GUI RPCs.

- MGR: In CBOINCClientManager::StartupBOINCCore() allow time for Client

to start up, to avoid repeated attempts which put spurious messages

"Another instance Another instance of BOINC is running" in

stderrdae.txt.

- client: simplify message describing scheduler request;

to get work request details, use <sched_op_debug>

- client: when preempting a process, remove it from memory if:

1) it uses a coprocessor

2) it has checkpointed since the client started

3) it's being preempted because of a user action

(suspend job, project, or all processing)

or user preference (time of day, computer in use)

- client: clear debts when reset project

- client: respect work-fetch backoff for non-CPU-intensive projects

- client: for non-CPU-intensive project, fetch new job

if no currently running jobs

- client: skip non-CPU-intensive projects in debt calculations

- manager: show resource backoff times correctly

- client: if we're doing an RPC (for whatever reason)

to a non-CPU-intensive project without a job, ask for one.

- client: change the LTD policy so that

1) net adjustment for eligible projects is zero;

2) max LTD is zero



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

Has anyone tired it?

Has anyone tired it?

Just installed it on Vista x64 + 2x 8800GS--It aborted all current tasks (WCG and GPUGrid) and re-DLed new ones. Currently it has only DLed 2x GPUGrid WUs--it has always been 4x WUs in every previous version. Cpu usage is 0-2%.

Time to Completion is ~ 1hr 13mins....I doubt that is correct, but that's what it's showing for both WUs. Time to Completion is steadily ticking upward, but Cpu usage moves up 1sec for evey ~23secs of realtime.


It's only been installed for ~10mins, so we'll see how it goes....


Manual update retrieves no new WUs on WCG or GPUGrid. I should have a larger cache on both projects, but things are running atm.

Updated driver from 180.48 to 181.22....no noticeable difference....

I installed BOINC 6.6.3 on two home computers last night and no significant problems so far, though I did see something similar to naja's, where I tried to fetch GPUGrid work and didn't the first time, but forced a second update and it did get some work.

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

Yesterday I upgraded BOINC 6.4.5 to 6.6.3 without any problems on an Intel Quad Q6600 with WinXP SP3.
Although it requests very often new work units, it doesn't get too much work (in contrast to a BOINC 6.2.2 install I had tried before).

I installed BOINC 6.6.3 on two home computers last night and no significant problems so far, though I did see something similar to naja's, where I tried to fetch GPUGrid work and didn't the first time, but forced a second update and it did get some work.

N

Just installed 6.6.3 into another rig. It did not abort the WUs, etc. Started up, benchmarked and went to work--NP. But this machine is coming from 6.3.21, so I would say that's the difference.

The other rig was updated from 6.4.5.

Edit: Cpu usage is high on this rig....~25%, but I am willing to assume atm that it's because of the older WUs.

So far everything seems good, except losing all of the work and WUs during the change-over....

So far everything seems good, except losing all of the work and WUs during the change-over....

I upgraded about 6 hours ago on both machines with no problems so far.

I've had problems with the installer not stopping the GPU task cleanly in the past so I suspended all activity before running the installer. I let the installer shut down the boinc client and the boinc manager though. I didn't loose any work units doing it that way, but then I am using the Win 32 bit variant and you are on the Win 64 bit.

Phoneman1

It can't seem to download any WU.
____________

I lost all WUs when I went to 6.4.2 or 6.4.5 (I think I installed 6.4.2 on both though). I switched the 1 rig back to 6.3.21 and the other to 6.4.5. Today when I switched from 6.4.5-I lost all WUs, but not switching from 6.3.21.

Going into 6.4.? I lost all WUs and coming out of it--same thing.

I've switched many times between various versions of BOINC 6.xx (both forward & backward & even 5.xx & including 6.4.1, 6.4.2, 6.4.5, 6.3.21) and have never lost any WUs in any project.

Everything is OK with WUs during upgrade, as usually. But it doesn't request work for gpugrid automatically! I am forced to make it by my hands again!!! Aggghhhrrrrr.... Is it so difficult for NORMAL programmer to fix this bug?!
____________
From Siberia with love!

Everything is OK with WUs during upgrade, as usually. But it doesn't request work for gpugrid automatically! I am forced to make it by my hands again!!! Aggghhhrrrrr.... Is it so difficult for NORMAL programmer to fix this bug?!

Has anyone tired it?

I couldn't get any new work GPU units on 2 different Box's using 6.6.3 ...

The 6.6.3 is running fine , but there are some changes I don't like. I can't see the amount of called work and had on one PC the situation, that he crunched all WUs and would not call new work 'til the last WU had less than 2 hours to work.

I don't like it, if the BM works like a black box and I get no information. I've described this on the Boinc dev forum
____________

Well, the good news is that there was only one major bug in 6.6.3 in calculating LTD ... which may very well mean that you will have trouble getting work ... :)

I think the fact that GPU LTD is zero now is by design and not a bug. I am not sure what it would be if I was running another GPU project. It looks to me like they are separating the work fetch mechanisms for CPU and GPU type projects.

Phoneman1

I think the fact that GPU LTD is zero now is by design and not a bug. I am not sure what it would be if I was running another GPU project. It looks to me like they are separating the work fetch mechanisms for CPU and GPU type projects.

Phoneman1

Yes, that is the intent. Also making minor changes for non-CPU projects ...

If you are attached to lots of projects JM VII found issues that indicate that you can run dry of work with 6.6.3 ... YMMV

SAME PROBLEMS HERE!

6.6.3 will not get new work from GPUGRID for me.

Went back to 6.4.5 and instantly it got 2 new WU's for me.

They just cannot get this right can they!

SAME PROBLEMS HERE!

Anyone having problems getting GPU tasks on Win 32 bit or Linux 32 bit with 6.6.3???
Phoneman1

I am experiencing GPUGrid work fetch problems under BOINC client 6.6.3 after upgrading several days ago. I have run out of work and with repeated attempts to get work manually including resetting the project without success.

There is definitely something wrong in the BOINC client work fetch logic that allows the PC to run dry and not fetch work when there are 2 graphics cards and only one active WU being processed and none in queue.

At 2:25 PM EST today, it is trying to download work by requesting new tasks, but nothing is being returned....this could be a GPUgrid.net work availablity problem again? Or BOINC...not sure.

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

There is a major bug in 6.6.3 which Dr. Anderson fixed related to the calculation of LTD. There are varying and different problems with all the 6.6.x versions from dot zero to dot three ...

I warned you below to be wary of 6.6.3 ... :)

I actually did look at the code and there was an initialization error that though I cannot predict the exact ways that it would bite you, will eventually bite you ...

Thanks Paul.

I've been watching this forum as well I'm on the alpha dist list at BOINC and like to test new releases when they come out. I'd love to get my hands on a new build to see if the fix(es) to 6.6.3 work for me. In the mean time I guess I'll have to go back to an earlier BOINC client release for now.

Neil

Works ok for me on two machines, vista64 and xp32; no problems

I just had to downgrade from 6.6.3 because it fetched way too much WUs of a CPU intense project. :-(

I thought it was OK at first also. But there was no way I could get more work to fill the queue.

6.6.3 downloaded 300 321LLR PG WU's overnight when my cache was set to 1 day.
Even after detaching from PG and reseting GPUGRID, still no new work.


Switched to 6.5.0 and its been perfect all day. It grabs GPU's no problem, and it runs 4+1 & 4.2 w/o issue so far.

Just a quick up date: No problems here. 2 rigs: Vista 64 3x 8800GS (total). Unless something changes....I'm going to stick with this for a while....

Initialization problems in code are usually the hardest to find because the system under many conditions can appear to be running correctly. In this case, the testing variable is not set with the initial value of the first project as the scanning loop begins. Now, it is entirely possible that the value that the variable has at the beginning of the loop is "close" enough so that it will do a proper scan ... but in other cases the first project in the list should be the value in the testing variable ... and it is never set ...

What that means, of course, is that you can run into trouble immediately, or more likely after running for a bit. What disappoints me the most is that no new build was made because aside this bug the build might have been the leap forward we were hoping for that finally started to address the issues we have with the GPU / CPU loads ...

Initialization problems in code are usually the hardest to find because the system under many conditions can appear to be running correctly.

I don't recall you mentioning the initialize issue on the mailing list. Do you have a snippet of code you could provide where you think the issue is, or is that the LTD fix Dr A has done?

It seems the suspend/resume buttons is the only fix so far in 6.6.4. The fact they didn't want to build a new version suggests they may be aware of more bugs and want to include (or are working on) fixes for them. Or maybe they just want to give us the weekend to give 6.6.3 a shake down.

There are a few reports of work-fetch issues popping up in boinc_alpha with the debug logging so there is a fair bit of information there for the guys to examine. I don't know if you subscribe to it or just boinc_dev? Maybe you should mention your concern with the code change.