According to the thread "Development BOINC 6.10.13 released" in the Number crunching forum of Seti@Home there are a number of Ati related issues fixed in BOINC 6.10.12. The unofficial change log mentions the following:

- client: if downloaded project list file is garbage, ignore it.
- all: accept <foo /> as an XML bool
- client: Apparently it is valid for the autoproxy to return successful API completeion but a null proxy list. Check for the null instead of crashing.
- client: only support one of the ati13* plan classes at a time. A couple users had not updated their amdcal* runtime libraries after upgrading catalyst drivers. This was leading to crashes of the project applications when work was supplied looking for the old DLL names.
- client: fix a handle leak I just introduced (From: Andreas a.k.a Gipsel)
- lib: Fix memory/resource leak. (From Nicolás Alvarez)
- lib: Add additional ATI descriptions.
- lib: Fix some inaccurate ATI capabilities in certain cards. (From: Andreas a.k.a Gipsel)
- lib: Fix memory/resource leak. (From Nicolás Alvarez) (reprise)
- client: restore calDeviceGetInfo(), add its info to COPROC_ATI struct (some plan class might need to know this).
- Code cleanup.
- client: better behavior if a GPU goes away:
1) if an APP_VERSION is missing a coprocessor, don't delete it and its files. (If the coprocessor returns, we won't need to re-download)
2) if a RESULT uses an app version that is missing a coprocessor, abort it (rather than deleting it). The client will report the result on the next scheduler RPC, and the server will make a new instance.
- client: fix bug where if you change project "no CPU/NVIDIA/ATI" prefs and update, the change wouldn't take effect until client restart.
- client: fix bug in enforcement of "no CPU/NVIDIA/ATI" prefs
- client: make the order of the result vector consistent with the order used to select coproc jobs
- client: improve coproc_debug messages
- client: if a task is running, uses a GPU, and the system has >1 GPU, append text to its resource string saying which GPU it's using
- manager: tweak Task properties text
- DIAG: Suspend threads right before extracting their context and then resume them afterwards. Otherwise we could end up in a deadlock state where both the main thread and a support thread are attempting to use the same system resource. In the last situation it was way down in Winsock.
- DIAG: Don't resume after the thread has been suspended, otherwise the thread stack may be trashed after extracting the context. This should still be okay though as by the time the diagnostics framework has gotten here it has already downloaded all the symbols it'll need.

Nice, Gipsel is in there!

By the way, the 6.10.13 change log has the following:

- client: fix crashing bug introduced in [18605]

Do the fixes in 6.10.12 mean we don't have to rename the DLL's anymore? And could this possibly mean we can now use the latest Catalyst drivers with Milkyway on XP? Uhm, actually, what does it all mean? Does anybody know if this will have any effect on the way we run the Ati GPU version of Milkyway@Home?

Would someone be kind enough to provide me with the link to the newer BM versions - say the 6.10.xx types.

I have been there before but forgot the URL.

The versions I specifically look for are compatible with Windows XP 32 bit

Getting 6.10.1 now, thanks! That is if ADSL contention allows me to!

---

Go away, I was asleep

Well Boinc has them and others I have seen as well.

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

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

Would someone be kind enough to provide me with the link to the newer BM versions - say the 6.10.xx types.

I have been there before but forgot the URL.

The versions I specifically look for are compatible with Windows XP 32 bit

Getting 6.10.1 now, thanks! That is if ADSL contention allows me to!

If you are getting a 6.10 version, stick to .3, .7, .11, and .13 all the others have serious problems that will eventually bite you. Note that .13 is newest and highest risk to use though the changes from .11 are relatively minor.

I'm seeing some really BAD behaviour with BOINC 6.10.13 and .10 before it.

I have Collatz and MW cached. I have 2 GPUs - a 4850 and a 4870. MW is set up with 0.33 ATI in an app_info file and Collatz is set with its default which is 1.0 ATI. Resource share is 54% MW and Collatz 3%. (SETI 20%, Aqua 20%, Spinhenge 3%). I'm only going to describe the GPU behaviour.

When BOINC is running only MW it runs 3 wu's on each card which is the deired behaviour. When it schedules Collatz and BOINC to run it stops 3 MW wu's and starts a Collatz wu, which is also the desired behaviour. But its which 3 MW wu's it stops is the problem. BOINC stops 1 wu on one card and 2 on the other, then starts Collatz on the card it has 2 MW wu's running. Needless to say the Collatz wu takes forever and the 2 MW wu's also take longer than with 3 running.

But wait, that's not all. I've seen the situation where 2 Collatz wu's are scheduled to run and it tries to run them both on the same card, leaving one card idle. I have also seen the correct behaviour of 1 wu per card. Go figure.

Back to micromanaging BOINC. BUGGER!

Does it work correctly if you set it to run 1 MW WU at a time?

Does it work correctly if you set it to run 1 MW WU at a time?

It does for me...

When you opt to have 3 MW tasks "running" at the same time in theory on one card, they are not really running at the same time. I know I asked this of Gispel (CP) elsewhere and this is what he said... what you may be gaining is to shave off a start up second or so per task. The problem is that the BOINC Resource Scheduler does not know about this and does not properly account for it when changing between projects.

You may also need his latest beta .20b for tasks here because of another issue I found that seems to be cleared up with it ... lastly I only say it works if you are also running 2.05 on Collatz... :)

But I have been running the two projects for the last day and have had no issues with task handover or running them on the correct GPU. Then again, I never did like running 3 MW tasks "at the same time" ...

Does it work correctly if you set it to run 1 MW WU at a time?

It does for me...

When you opt to have 3 MW tasks "running" at the same time in theory on one card, they are not really running at the same time. I know I asked this of Gispel (CP) elsewhere and this is what he said... what you may be gaining is to shave off a start up second or so per task. The problem is that the BOINC Resource Scheduler does not know about this and does not properly account for it when changing between projects.

You may also need his latest beta .20b for tasks here because of another issue I found that seems to be cleared up with it ... lastly I only say it works if you are also running 2.05 on Collatz... :)

But I have been running the two projects for the last day and have had no issues with task handover or running them on the correct GPU. Then again, I never did like running 3 MW tasks "at the same time" ...

So, essentially, the "at the same time" are similar to timeslicing...and may be just "smoke and mirrors", much like the "RAM Booster" software programs for Win95 and higher (not talking about QEMM here)...

Maybe there should be some sort of FAQ or README that goes with the GPU applications to explain things like this. It may cut down on some of the angst.

Does it work correctly if you set it to run 1 MW WU at a time?

It does for me...

That's what I suspected :-)

You may also need his latest beta .20b for tasks here

And where can that be found?

Maybe there should be some sort of FAQ or README that goes with the GPU applications to explain things like this. It may cut down on some of the angst.

Actually there is a readme included in every download of the GPU applications that explains these things. The people only have to read it ;)

Maybe there should be some sort of FAQ or README that goes with the GPU applications to explain things like this. It may cut down on some of the angst.

Actually there is a readme included in every download of the GPU applications that explains these things. The people only have to read it ;)

Yeah...that's the hard part...getting people to read...

If there's not really that much benefit and it introduces more confusion, why not just remove that "capability"?

Maybe there should be some sort of FAQ or README that goes with the GPU applications to explain things like this. It may cut down on some of the angst.

I spent the better part of several years doing just that to no avail ... I could not get people to spend even a few moments of their time to go look something up ...

Does it work correctly if you set it to run 1 MW WU at a time?

I'll try that when I get home tonight.

As for the other comments....

Can CP give a better description of the time slicing of MW tasks on the GPU?

BTW...I've read the readme file many times over the past few months and am pretty certain it says nothing about the issues I have indicated. Yes it says doing more than 2 or 3 wu's may not benefit over crunching.

In any case. If Collatz says 1.0 ATI and MW says 0.33 ATI, how could BOINC even schedule a MW and Collatz to run on one GPU?

I'd also like to know where 0.20b can be found....planet3dnow maybe?

.....BTW...I've read the readme file many times over the past few months and am pretty certain it says nothing about the issues I have indicated......

Collatz v2.04, 2.05 and 2.05b readme file regarding the n parameter which is the same thing but only for use on a non ATI aware BOINC version: "If you run more than one GPU project (Collatz and Milkyway), this will be a shared setting and should be the same for both in all cases!"

Maybe there should be some sort of FAQ or README that goes with the GPU applications to explain things like this. It may cut down on some of the angst.

I spent the better part of several years doing just that to no avail ... I could not get people to spend even a few moments of their time to go look something up ...

Well, if running them "at the same time" really does not have a significantly measurable benefit to the total runtime, then as a developer, I wouldn't include it, especially if it causes additional confusion and/or anger because things don't "work right"... That's just my opinion mind you... I don't have the skill in C or C++ to pour through things like what has been done, so I appreciate what has been done, but if the pros of doing it are outweighed by the negative side-effects, then why put it in there?

Maybe there should be some sort of FAQ or README that goes with the GPU applications to explain things like this. It may cut down on some of the angst.

I spent the better part of several years doing just that to no avail ... I could not get people to spend even a few moments of their time to go look something up ...

Well, if running them "at the same time" really does not have a significantly measurable benefit to the total runtime, then as a developer, I wouldn't include it, especially if it causes additional confusion and/or anger because things don't "work right"... That's just my opinion mind you... I don't have the skill in C or C++ to pour through things like what has been done, so I appreciate what has been done, but if the pros of doing it are outweighed by the negative side-effects, then why put it in there?

Because people wanted it ... and it may increase throughput in some cases ... if I am running tasks off at 55 seconds or less then a one second improvement in hand-over from one MW task to another is pretty significant... for those that want maximum performance/throughput...

But like all settings it is use at your own risk as is all anon platform installs. If it does not work right it is on your head.

I would rather CP (Gispel) and UCB gave us more options than less because there are many situations where the available controls are just not good enough to let us manage the operation of the system. Sadly the UCB philosophy is "trust us, we be smarter than you" rather than adding some common sense controls that would allow us flexibility ...

To pick one not at random, we asked that the "return results immediately" be configurable by project not by client... why? Because I want to return results for GPU Grid ASAP as it helps the project and me (credit bonus for early returns) but maybe not for MW because of server load... I can go on ... :)

Maybe there should be some sort of FAQ or README that goes with the GPU applications to explain things like this. It may cut down on some of the angst.

Actually there is a readme included in every download of the GPU applications that explains these things. The people only have to read it ;)

Pfff read, omg he said read and look something up whats that xD
Serious Paul, CP stop saying such nasty things ;)

---

Its new, its relative fast... my new bicycle

My experiments have indicated that running 2 Collatz tasks concurrently takes slightly longer per task than running one at a time. With MilkyWay the runtime for each individual task is the same but it results in a small increase in daily throughput, possibly about 5% on my HD 4890. The shorter the task and the faster the card the greater the increase in daily throughput would be.

My HD 4890 has no trouble running 2 MilkyWay tasks concurrently and it means the GPU load is more constant not dropping to zero every 40 seconds during changeover. This may be better for card longevity although it results in a higher average temperature so is unsuitable here for hot days.

My HD 3850 however was very unstable when running 2 MilkyWay tasks concurrently and regularly froze, requiring a stop and restart of BOINC. It was very stable when running one at a time.

My dual 4850 did 3 per card untill the last 0.20 version after which i got freezing desktop problems so set it back to 2 per card
I think 3 units per 4890 should be bit better since its much faster, but then again i don't have such a beast.

---

Its new, its relative fast... my new bicycle

My experiments have indicated that running 2 Collatz tasks concurrently takes slightly longer per task than running one at a time. With MilkyWay the runtime for each individual task is the same but it results in a small increase in daily throughput, possibly about 5% on my HD 4890. The shorter the task and the faster the card the greater the increase in daily throughput would be.

My HD 4890 has no trouble running 2 MilkyWay tasks concurrently and it means the GPU load is more constant not dropping to zero every 40 seconds during changeover. This may be better for card longevity although it results in a higher average temperature so is unsuitable here for hot days.

My HD 3850 however was very unstable when running 2 MilkyWay tasks concurrently and regularly froze, requiring a stop and restart of BOINC. It was very stable when running one at a time.

Interesting about your 3850. I've never seen mine lock up and it's running 2 at a time - > but then again on my 4850 / 4870 combination I get regular lockups. I might try n1 for those and since I'm away for the weekend it may be very fortuitous timing.