I saw a Beta Boinc version 6.6.3 in the 'all downloads' area tonight. But I don't see any mention on the message boards about it. I wasn't able to complete the download before the boinc servers appear to have gone belly up tonight, so haven't tried it out yet. Does anyone know what was fixed/changed?

I'm anxiously hoping it fixes the problem with my GPU stalling and not processing waiting WUs. Fixing the constant download of new WUs would be great too.

Thanks!

See BOINC post 22743

It probably still needs more work but from Rom Walton post on mailing list.

This release has many fixes for work-fetch and CPU/GPU scheduling.

Change Log:

- 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

Ok, now we know what it fixes but the question now is How does it handle on the road? Has anybody tried it out here in the real world?

---

PROUD MEMBER OF Team Starfire World BOINC

Ok, now we know what it fixes but the question now is How does it handle on the road? Has anybody tried it out here in the real world?

First report from the maillist is that the scheduler is overly pessimistic. If you are attached to a LOT of projects and do not have an always available internet connection, then there is a chance of running dry.

May be fine for more 'normal' use. Anyone able to comment?

I'm guessing there's still some flux in the bits to settle out yet. Watch for comments!

Happy crunchin',
Martin

---

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)

Ive istalled it on one of my hosts. It don't want to download new units.

---

Ok, now we know what it fixes but the question now is How does it handle on the road? Has anybody tried it out here in the real world?

Here's what I have reported to boinc_alpha:

1:
Windows Vista x64 - there is no update in the BOINC GUI in any of the folders. Only way to see progression and status is to look at the logs.

The "Disk" folder only contains 100% black pie charts.

As for "Messages" only the messages from the startup of the GUI is displayed ("restarting task xxx" and "Reporting x completed tasks...")

Browsing "Tasks" will only display blanks/placeholders for S@H WUs, but will display all AP WUs..

If I uninstall and install 64-bit BOINC, the x64 GUI will simply crash alltogether - as it did in version 6.6.2.

>From stdoutgui.txt:
[01/29/09 00:09:29] TRACE [4464]: RPC_CLIENT::init connect 2: Winsock error '10061'
[01/29/09 00:09:29] TRACE [4464]: RPC_CLIENT::init connect on 672 returned -1
[01/29/09 00:09:30] TRACE [4464]: init_asynch() boinc_socket: 676
[01/29/09 00:09:30] TRACE [4464]: init_asynch() connect: -1
\\RebootPending.txt' (error 2: the system cannot find the file specified.)

2:
Windows Vista x64 - 6.6.3 will crash when selecting "Tasks" folder on Windows Vista x64 - it terminates with the following info:
Faulting application boincmgr.exe, version 6.6.3.0, time stamp 0x497f733c, faulting module MSVCP80.dll, version 8.0.50727.762, time stamp 0x45711f83, exception code 0xc0000005, fault offset 0x0000000000002c80, process id 0xc10, application start time 0x01c981a74a42994b.

This is identical error to version 6.6.2

3:
Windows Vista x64 - the Cuda app (6.08) will use 100% cpu after running several WUs successfuly. Then at the time of starting a new WU and in the feeding-to-the-gpu-process it will not progress beyond 0,000%-0,050% and will consume 100% until boincmgr.exe is closed and all the apps are gone from the Windows tasklist. Then, when boincmgr.exe is restarted, the same "hung" WU will now be properly processed and receive credit. Problem in the CPU-toGPU handling, and perhaps also memory leak/corruption in GPU. Same GPU has been used for GPUGrid for many weeks without one problem, so it's a S@H issue

Morten Ross

---

Morten Ross

You can post this in BOINC Message Boards.

---

Bit early to say yet, because there's little Set work around - I ran out last night. Which considering the load 6.6.2 sent me is no bad thing ;)

6.6.3 sat here waiting since about 13:00 Uk time :) As it's a beta, time will tell.

I have tried it on two different XP 32 boxes. It seemed to work properly and would harrass all the projects regularly for cuda work. It never ran out of work and kept both cpu's and gpu fed. Problem is, it crashes whenever you try for view the tasks tab. Projects and messages work properly.

---

"The most exciting phrase to hear in science, the one that heralds new discoveries, is not Eureka! (I found it!) but rather, 'hmm... that's funny...'" -- Isaac Asimov

When I tried it Boinc Manager locked up on every machine I tried it on. 4 of them. Immediately reverted back to 6.6.0.

---

Boinc....Boinc....Boinc....Boinc....

seems to be working fine - 64bit on my i7 and 32bit on my netbook

---

seems to be working fine - 64bit on my i7 and 32bit on my netbook

That is the problem. It seems to work fine ... there is an initialization bug in the calculation of LTD. If you only run one project you may never see the problem ... but if you run more than one project you can easily run out of work...

seems to be working fine - 64bit on my i7 and 32bit on my netbook

That is the problem. It seems to work fine ... there is an initialization bug in the calculation of LTD. If you only run one project you may never see the problem ... but if you run more than one project you can easily run out of work...

The definition of "overworked" changed dramatically. Only the project with the highest LTD is not over worked on most of my machines. Projects that are over worked do not have as large work vuffers allowed as those that are not overworked.

The max LTD is 0 rather than the LTD being 0. No, this was not my decision.

This means that any project that you add will come in with the highest LTD (along with the project that has not been asked for work for the longest time).

---

BOINC WIKI

seems to be working fine - 64bit on my i7 and 32bit on my netbook

That is the problem. It seems to work fine ... there is an initialization bug in the calculation of LTD. If you only run one project you may never see the problem ... but if you run more than one project you can easily run out of work...

The definition of "overworked" changed dramatically. Only the project with the highest LTD is not over worked on most of my machines. Projects that are over worked do not have as large work vuffers allowed as those that are not overworked.

The max LTD is 0 rather than the LTD being 0. No, this was not my decision.

This means that any project that you add will come in with the highest LTD (along with the project that has not been asked for work for the longest time).

Only reinforces my comments in post 857887 but obviously I should have included BOINC programmers other than JM7.