BOINC 6.6.4 for Win32. Find more at dl directory.
Please test it and report here if any.

---

From Siberia with love!

I've installed already but on a PC without CUDA GPU and it run smootly. Later evening will try it on the serious machine.. :)

I hope it will solve some incompatibilities I am struggling with the 6.62 version...

BOINC 6.6.4 for Win32. Find more at dl directory.
Please test it and report here if any.

I have installed it on one non-cuda host. One annoying thing I have found is it refuses to check Orbit for work (even though they haven't got any). So if you get a project that isn't giving out work regularly it doesn't look like its going to connect to see if there is any. Maybe it will given a bit more time.

Apart from this annoyance it appears to be working fine so far, although I can't comment on cuda interaction. I'm running the WinXP (32 bit) version. There are OS-X, Windows x86 and Windows x64 versions available.

---

BOINC blog

As far as work fetch, there has been changes to the internal rules on projects that rarely have work, Orbit, LHC, SIMAP, etc. and it is not at all clear if these changes are the right ones or not.

More importantly, this is a major change in the work fetch processing so I would not hold up my hopes for this version to be bug free ...

As far as work fetch, there has been changes to the internal rules on projects that rarely have work, Orbit, LHC, SIMAP, etc. and it is not at all clear if these changes are the right ones or not.

More importantly, this is a major change in the work fetch processing so I would not hold up my hopes for this version to be bug free ...

I posted a copy of my message above on BOINC_alpha, so we'll see.

So far it hasn't tried requesting work from orbit, but has been trying Seti (they don't have any either at the moment). It appears to be working okay for those that do have work, or at least normally have work. Still haven't tried it on a cuda machine yet.

---

BOINC blog

As far as work fetch, there has been changes to the internal rules on projects that rarely have work, Orbit, LHC, SIMAP, etc. and it is not at all clear if these changes are the right ones or not.

More importantly, this is a major change in the work fetch processing so I would not hold up my hopes for this version to be bug free ...

I posted a copy of my message above on BOINC_alpha, so we'll see.

So far it hasn't tried requesting work from orbit, but has been trying Seti (they don't have any either at the moment). It appears to be working okay for those that do have work, or at least normally have work. Still haven't tried it on a cuda machine yet.

I installed in on a cuda-capable host and it doesn't get any work. Supposedly requests work but always gets 0 wu. I regressed back to 650 and it picked up work when it requested it, so there is some issue there with the scheduler requests.

---

BOINC blog

Just installed on CUDA capable machine and it runs OK...seems...at the moment:)

---

Please test it and report here if any.

Thanks for posting, but please be careful with your formulation. These new versions tend to be full of errors and when you say "please test it" it sounds official. But I'm sure the project doesn't want all the people to test these new development versions and to possibly get frustrated over new errors.

Sure, someone has to test.. but for the people who know what they're getting into the information + link is enough ;)

I'm saying this because I'm amazed at how many people are running 6.6.3 and are reporting problems, despite the fact that it quickly became obvious that 6.6.3 is broken.

MrS

---

Scanning for our furry friends since Jan 2002

I am trying to remember where I saw it, but I am sure I saw a report that 6.6.4 does not fetch from GPU Grid ... SaH forum? Not sure ... they back leveled and immediately got work ... FYI ...

I just trying to do all that depends on me for science developing, so please forgive me if I do something wrong... :-)

---

From Siberia with love!

I just trying to do all that depends on me for science developing, so please forgive me if I do something wrong... :-)

It is not wrong, it is just that the use of the Beta versions is fraught with risk and not all participants are aware of these risks.

We are a seemingly inconsistent in that we do recommend the use of 6.5.0 which *IS* a beta version but that is only after we have tried the alternatives and have found that it is the "best" compromise between operational capability and the buggy-ness of the release ...

Which is also why we usually follow a statement that 6.5.0 works for me, and that 6.4.5 also seems to work for most folks (both seem to have minor issues however).

I am trying to remember where I saw it, but I am sure I saw a report that 6.6.4 does not fetch from GPU Grid ... SaH forum? Not sure ... they back leveled and immediately got work ... FYI ...

That was me.

I went back to 6.5.0 after it kept saying it couldn't get any work from the 3 projects I was running (Einstein, GPUgrid and Seti). It was supposedly trying to get work but kept saying "received 0 results". Once I went back to 6.5.0 it managed to get work straight away for all 3 projects.

Also the other machine I had it on (non-cuda) refused to check Orbit for work. I know they don't have any but it has to try at least once to find out.

---

BOINC blog

I am trying to remember where I saw it, but I am sure I saw a report that 6.6.4 does not fetch from GPU Grid ... SaH forum? Not sure ... they back leveled and immediately got work ... FYI ...

That was me.

I went back to 6.5.0 after it kept saying it couldn't get any work from the 3 projects I was running (Einstein, GPUgrid and Seti). It was supposedly trying to get work but kept saying "received 0 results". Once I went back to 6.5.0 it managed to get work straight away for all 3 projects.

Also the other machine I had it on (non-cuda) refused to check Orbit for work. I know they don't have any but it has to try at least once to find out.

Mark, I just got an orbit task ... listed at 64 hours, which I will believe when I see it ...

I just trying to do all that depends on me for science developing, so please forgive me if I do something wrong... :-)

Nothing wrong, no offense or anything. Just a small side note on how to do it better :)

MrS

---

Scanning for our furry friends since Jan 2002

Updates included in 6.6.4. Do not download and use this BOINC client version unless you are technically proficient and are willing to return to an earlier version if it doesn't work.


Change Log:

- MGR: call UpdateSelection() from OnListRender() instead of from

RestoreSelections(). Fixes #837.

- MGR: Suppress Skin Manager error messages by default; enable them

only if the Manager is launched from the command line with an

argument -c or --checkskins.

- client: if we're making an RPC to a project because of user request,

clear the resource backoff times so that we potentially

can ask the project for work.

- lib: comment out perror()s in connection code.

- client: remove the "deadlines_missed" and "overworked"

clauses from RSC_WORK_FETCH::choose_project()

- client: restore notion of overworked;

if a project is overworked for a resource R,

don't fetch work for R unless there are idle instances

- GUI RPC: the "get all projects" RPC now also returns account managers

- GUI RPC: Fix compiler warning (missing return value).

- client: if user requests RPC, do it even if project is backed off

- manager: show backoff interval correctly

- client: update LTD correctly

- Work fetch / scheduler:

There are two mechanisms to prevent the scheduler from

sending jobs that won't finish by their deadline.

Simple mechanism:

The client sends the interval x for which CPUs are projected

to be saturated.

Given a job with estimated duration y,

the scheduler doesn't send it if x + y exceeds the delay bound.

If it does send it, x is incremented by y.

Complex mechanism:

Client sends workload description.

Scheduler does EDF simulation, sees if deadlines are missed.

The only project using this AFAIK is BOINC alpha test.

Neither of these mechanisms takes coprocessors into account,

and as a result jobs could be sent that are doomed to

miss their deadline.

This checkin adds coprocessor awareness to the Simple mechanism.



Changes:

Client:

compute estimated delay (i.e. time until non-saturation)

for coprocessors as well as CPU.

Send them in scheduler request as part of coproc descriptor.

- client: fixed bug that computed CPU estimated delay incorrectly

- client: the work request (req_secs) for a resource is the min

of the project's share and the shortfall.

- client: computation of # idle CUDA instances was wrong

- client: tweak work fetch messages

- client: buffer 2000 messages instead of 1000

- client: work fetch fixes

- client: there was a problem with how the round simulator

worked in the presence of coprocessors.

The simulator maintained per-project queues of pending jobs.

When a job finished (in the simulation) it would get

one or more jobs from that project's pending queue.



The problem: this could cause "holes" in the scheduling of GPUs,

and produce an erroneous nonzero shortfall for GPUs,

leading to infinite work fetch.



The solution: maintain a separate (per-resource, not per--project)

queue of pending coprocessor jobs.

When a coprocessor job finishes,

start pending jobs from the queue for that resource.



Another change: the simulator did strict reservation of coprocessors.

If there are 2 instances of CUDA,

and a 1-instance job is running in the simulation,

it wouldn't start an additional 2-instance job.

This also can cause erroneous nonzero shortfalls.



So instead, schedule coprocessors like CPUs, i.e. saturate them.

This can cause distorted completion time estimates,

but it's better than infinite work fetch.

- client: code cleanup

02/05/09 18:35:00|GPUGRID|Sending scheduler request: Requested by user.
02/05/09 18:35:00|GPUGRID|Reporting 1 completed tasks, not requesting new tasks
02/05/09 18:35:05|GPUGRID|Scheduler request completed: got 2 new tasks

Hmmm... %-)

---

From Siberia with love!