From the land of BOINC...

Earlier today we pulled the last round of stable clients and rolled back to the stable clients that were available in early December.

A bug was introduced in 6.10.25 where the core client would continuously download new work from projects where the total GPU ram was enough to run the GPU app but not enough was available at run-time to actually run the application without crashing. This bug was fixed in 6.10.46.

As a result of having to pull the previous stable build we are moving forward with the 6.10.50 build as a potential release candidate build. I have adjust the test grouping to enable all of them now.

We really need to get a new stable version of the Mac client out the door, CUDA support for the Mac is not in the current stable Mac client.

Please report your results, good or bad, as quickly as possible.

----- Rom

I'll start another thread with whats in 6.10.50 for those that are interested.

---

BOINC blog

Unless you're suffering from this particular problem, I wouldn't advise anybody to change their BOINC version just because of this status change. v6.10.43 is much better for general use than v6.10.18

Of course, if you have a CUDA card with limited RAM or an OS which uses a lot of VRAM, you may need to change, but the VRAM requirements of SETI/CUDA shouldn't ever be a problem if your card has 512MB or above.

From BOINC

BOINC 6.10.43/44 withdrawn
Due to a bug in .43/.44, the currently stable BOINC client has been rolled back to 6.10.18. The bug in question only affects volunteers using GPUs that do not have enough GPU RAM to execute their desired project applications. This bug is fixed in 6.10.46 or newer. 29 Apr 2010 20:50:51 UTC ·

Just UPDated all rig's to 6.10.43, last monday night, also
installed the new Unified Installer v 0.35 on my X64 rig, which went very smooth.
Also, apart from 3 faults (CUDA Optimized){Found triplets in a row....,which is always comming from my 9800GTX+ when it gets too hot. It was hot yesterday (26C), and the REScheduler 0.9 didn't restart BOINC or BOINC lost it's connection to Local Host. Seen it once, though.
Anyway, I'll keep an eye on it, so far so good...

---

I asked for an explanation on why we went back to .18, which doesn't have any prevention code whatsoever in place. Rom answered me:

Rom Walton wrote:

The previous behavior, what is in .18, is that the task instance just crashes, the project should then reduce the quota for the machine. The situation would eventually resolve itself so that the host was only getting one or two task instances a day.

From .25 through to .45, the host would just keep requesting new work without even attempting to launch the existing task instances. Eventually the HD would become full, if the preferences didn't prevent it. On one host 2000+ task instances were downloaded.

---

how about fixing the "gorging"!

this client (v6.10.43) http://setiathome.berkeley.edu/show_host_detail.php?hostid=4001951 downloaded 4000 work units on a binge over a couple of days, i had to disallow (no new tasks) work for about 12 days. today reschedule says it has about 710 work unit in the cache, i re-enabled work yesterday.

perhaps we need a blowout preventer, like a user settable max allowed workunits for gpu and another for cpu.

---

BOINC V6.10.43 or a version earlier don't take longer the CPU name from the registry like V6.10.18 it do, it take the info from somewhere other.
I guess from the same place like the opt. apps it do..

Why BOINC don't take longer the CPU name from the registry?


____________
[Optimized project applications, for to increase your PC performance (double RAC)!][Overview of abbreviations and smilies and their meaning.]

---

BOINC V6.10.43 or a version earlier don't take longer the CPU name from the registry like V6.10.18 it do, it take the info from somewhere other.
I guess from the same place like the opt. apps it do..

Why BOINC don't take longer the CPU name from the registry?

I wonder whether this is is connected with

detect CPU information via the cpuid instruction instead of the registry.

from v6.10.34 (and finished off in v6.10.35)

That's actually a very useful change: it allows BOINC to schedule, for example, SSE2 applications on Windows 2000 - the 'information' obtained via CPUID is much more to do with instruction sets than just the manufacturer's advertising slogan.

Read the AQUA thread No work sent: Aqua needs a CPU with SSE2 support - A64 X2 installed for an example of how it helped in real life.

how about fixing the "gorging"!

Which is exactly why that client version was pulled.

---

how about fixing the "gorging"!

this client (v6.10.43) http://setiathome.berkeley.edu/show_host_detail.php?hostid=4001951 downloaded 4000 work units on a binge over a couple of days, i had to disallow (no new tasks) work for about 12 days. today reschedule says it has about 710 work unit in the cache, i re-enabled work yesterday.

perhaps we need a blowout preventer, like a user settable max allowed workunits for gpu and another for cpu.

If you set reschedule1.9 to move Wu's to the CPU or GPU, of cause Boinc will ask for more work to refill the cache,

Claggy

how about fixing the "gorging"!

this client (v6.10.43) http://setiathome.berkeley.edu/show_host_detail.php?hostid=4001951 downloaded 4000 work units on a binge over a couple of days, i had to disallow (no new tasks) work for about 12 days. today reschedule says it has about 710 work unit in the cache, i re-enabled work yesterday.

perhaps we need a blowout preventer, like a user settable max allowed workunits for gpu and another for cpu.

If you set reschedule1.9 to move Wu's to the CPU or GPU, of cause Boinc will ask for more work to refill the cache,

Claggy

If that were the extent of it, there would be no problem...

But there is sometimes an unintended rebound effect that causes Boinc to request FAR more work than would be required simply to refill the cache that was moved.

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

BOINC V6.10.43 or a version earlier don't take longer the CPU name from the registry like V6.10.18 it do, it take the info from somewhere other.
I guess from the same place like the opt. apps it do..

Why BOINC don't take longer the CPU name from the registry?

I wonder whether this is is connected with

detect CPU information via the cpuid instruction instead of the registry.

from v6.10.34 (and finished off in v6.10.35)

That's actually a very useful change: it allows BOINC to schedule, for example, SSE2 applications on Windows 2000 - the 'information' obtained via CPUID is much more to do with instruction sets than just the manufacturer's advertising slogan.

Read the AQUA thread No work sent: Aqua needs a CPU with SSE2 support - A64 X2 installed for an example of how it helped in real life.

Thanks!

Ohh - sh**!
Then I would need to stay with V6.10.18, because I like to edit the CPU name in the registry.. :-D

Which version have the prob solved if one SETI@home DL server is offline?
< V6.10.34 ?


____________
[Optimized project applications, for to increase your PC performance (double RAC)!][Overview of abbreviations and smilies and their meaning.]

---

I have been having no problem with the 10.43 should I reinstall 10.18? Not running GPUs on any machine

---

I have been having no problem with the 10.43 should I reinstall 10.18? Not running GPUs on any machine

Since the .43 problems only occur with CUDA, you don't need to downgrade (if all else is well).

Gruß,
Gundolf

---

Computer sind nicht alles im Leben. (Kleiner Scherz)

SETI@home classic workunits 3,758
SETI@home classic CPU time 66,520 hours

BOINC V6.10.43 or a version earlier don't take longer the CPU name from the registry like V6.10.18 it do, it take the info from somewhere other.
I guess from the same place like the opt. apps it do..

Why BOINC don't take longer the CPU name from the registry?

I wonder whether this is is connected with

detect CPU information via the cpuid instruction instead of the registry.

from v6.10.34 (and finished off in v6.10.35)

That's actually a very useful change: it allows BOINC to schedule, for example, SSE2 applications on Windows 2000 - the 'information' obtained via CPUID is much more to do with instruction sets than just the manufacturer's advertising slogan.

Read the AQUA thread No work sent: Aqua needs a CPU with SSE2 support - A64 X2 installed for an example of how it helped in real life.

Thanks!

Ohh - sh**!
Then I would need to stay with V6.10.18, because I like to edit the CPU name in the registry.. :-D

Which version have the prob solved if one SETI@home DL server is offline?
< V6.10.34 ?

2nd question.. ;-)

Maybe I have the possibility for to disable this CPU detection function with help of an entry in my cc_config.xml ?
Or a way that BOINC take again the name from the registry? :-)


____________
[Optimized project applications, for to increase your PC performance (double RAC)!][Overview of abbreviations and smilies and their meaning.]

---

[quote]Which version have the prob solved if one SETI@home DL server is offline? < V6.10.34 ?

6.10.19

Maybe I have the possibility for to disable this CPU detection function with help of an entry in my cc_config.xml ? Or a way that BOINC take again the name from the registry? :-)

If you want to edit it so desperately, edit it in client_state.xml as that's where it's stored and (re)read from by the client.

There are no flags in the core client configuration file or elsewhere to set as the change helps BOINC identify the CPU correctly, and show all its instruction capabilities, now independent from those supported by your OS only.

---

Which version have the prob solved if one SETI@home DL server is offline? < V6.10.34 ?

6.10.19

That would be v6.10.24

Maybe I have the possibility for to disable this CPU detection function with help of an entry in my cc_config.xml ? Or a way that BOINC take again the name from the registry? :-)

If you want to edit it so desperately, edit it in client_state.xml as that's where it's stored and (re)read from by the client.
[...]

But this would be only a very temporary solution.. or?
AFAIK, the client_state.xml file will be continuously rewritten, or?
So maybe everytime my BOINC client contacted the SETI@home server my edit is away?


____________
[Optimized project applications, for to increase your PC performance (double RAC)!][Overview of abbreviations and smilies and their meaning.]

---

So maybe everytime my BOINC client contacted the SETI@home server my edit is away?

No, every time that the client restarts that info is rewritten. The CPU detection only happens at BOINC start-up, just as GPU detection only happens at that time.

---

So maybe everytime my BOINC client contacted the SETI@home server my edit is away?

No, every time that the client restarts that info is rewritten. The CPU detection only happens at BOINC start-up, just as GPU detection only happens at that time.

Thanks!

Hmm..
Just for the dummies like me.. :-D

I start BOINC - go to the boinc folder search the client_state.xml file - edit of the CPU name - save - ready.

So, everytime now BOINC contact the SETI@home server the edited CPU name will be send and in the PC overview showed?

But - is there an easy way for automatic edit of the client_state.xml file possible, which will happen after every start of BOINC? :-)


____________
[Optimized project applications, for to increase your PC performance (double RAC)!][Overview of abbreviations and smilies and their meaning.]

---

So maybe everytime my BOINC client contacted the SETI@home server my edit is away?

No, every time that the client restarts that info is rewritten. The CPU detection only happens at BOINC start-up, just as GPU detection only happens at that time.

How do you manage to edit client_state without restarting BOINC? ;-)