OK works again (on the 4850) thx for bringing the work generator back.

So the other question in direction Travis now is, is 38x0 really dead now or can we still expect something? Only to know if i can deactivade it. It still computes until 100% in the normal 7 Minutes like always but it dont stops then computing on 100%. So the WU never stops/finish and never get uploaded.

What do you mean by 38x0?

--Travis

OpenCL does not work on the HD3850 so they have been using the older 0.82 app to crunch with, which was working until the recent changes.

Good morning!

Correct , it was running with the 0.82 app :)

---

DSKAG Austria Research Team: http://www.research.dskag.at

Hi,
it is right that for this time my 3850 has no new work , because new WUs are failing? and there will be no suport for?
Thanks JHAPA

---

OK works again (on the 4850) thx for bringing the work generator back.

So the other question in direction Travis now is, is 38x0 really dead now or can we still expect something? Only to know if i can deactivade it. It still computes until 100% in the normal 7 Minutes like always but it dont stops then computing on 100%. So the WU never stops/finish and never get uploaded.

What do you mean by 38x0?

--Travis

OpenCL does not work on the HD3850 so they have been using the older 0.82 app to crunch with, which was working until the recent changes.

Good morning!

Correct , it was running with the 0.82 app :)

Okay cool, I'm gonna take down the searches that aren't working on the 38x0 and put up some new ones which should. Hopefully this clears up the issue.

---

well it appears this thread has been dormant for a full week now...shame i gotta bring it back. i was happy to say that my HD 6950 had racked up ~9,000 consecutive valid tasks over the last 10 or so days, but today i got another "ps_separation_14_2s_null_3" error, specifically a "ps_separation_14_2s_null_3_1338573431_354_2" task. i don't know if its anything meaningful or not, but i felt it was my duty as a project participant to at least report it, since its one of the sub-types of tasks Matt is testing in this thread. i'm hoping it was just a rare glitch, but i have my doubts b/c the stderr output file looks like it crunched normally.

i'll mention that i had a completed task get marked invalid today as well. the stderr output again looked like it ran normally. so i looked at the wingmen and realized that all 4 of them got errors, rendering my result useless. though i know there was no fault on my end, i thought i'd post about it b/c its a different type of task than the one discussed above...specifically, this task is a "de_separation_14_2s_05_3_test_1_rand_1339497601_758925" task.

anyhow, just thought i'd let the developers and testers know...i'm not reading into it too much at this point, but i'll post more if the errors start rolling in...

---

I just tried a couple of WU on a 5870 I acquired. Both ran to 100% and then went computation error. New/old problem again?

I just tried a couple of WU on a 5870 I acquired. Both ran to 100% and then went computation error. New/old problem again?

Are you still using the v0.82 CAL app? The current WUs seem to be incompatible with it on 64-bit systems, but your GPU is OpenCL capable, so you could try that.

---

I just tried a couple of WU on a 5870 I acquired. Both ran to 100% and then went computation error. New/old problem again?

Are you still using the v0.82 CAL app? The current WUs seem to be incompatible with it on 64-bit systems, but your GPU is OpenCL capable, so you could try that.

I've stuck with the 0.82 because the later ones caused the GPU usage and power draw to be all over the place which I was not comfortable with. Even with an app_info to try and control GPU% didn't help. I may try the later app but I hope they can solve this 64 bit issue.

---

I've been trying to get some new tasks for my XP 32 bit machine without success. Here's the message log.

6/16/2012 10:03:38 AM | Milkyway@Home | work fetch resumed by user
6/16/2012 10:03:40 AM | Milkyway@Home | update requested by user
6/16/2012 10:03:45 AM | Milkyway@Home | Sending scheduler request: Requested by user.
6/16/2012 10:03:45 AM | Milkyway@Home | Not reporting or requesting tasks
6/16/2012 10:03:46 AM | Milkyway@Home | Scheduler request completed

Tried a reset, didn't help.

NM: Got it working.
FWIW I still find that the 1.02 app causes my kill-a-watt meter to fluctuate by as much as 60 watts on 64 bit and 25 watts on 32 bit while I never noticed the 0.82 app fluctuate by more than 5 watts.

Sorry to harp on again about the HD3850 AGP issue ...

Replaced Windows 7 SP1 (64-bit) with XP SP3 (32-bit) - so, same hardware. All .NET/drivers/updates/BOINC reinstalled (see previous post for details).
Since last night I have downloaded fresh new WUs and processed over 70 GPU tasks OK (one fail, probably a fluke during update of .NET).
So ...
W7 64-bit/HD3850 AGP & existing MW@H GPU tasks ALL fail with "Computation error"
whereas ...
XP 32-bit/HD3850 AGP & existing MW@H GPU tasks work OK.

What do you reckon?

Sorry to harp on again about the HD3850 AGP issue ...

It's not really a HD3850 AGP issue, it's a Win7-x64 CAL application issue, maybe not even limited to Win7, can be all 64-bit Windows versions (even if I don't see anyone here with 64-bit XP or Vista complaining about these errors). My HD3850 is PCIe and nanoprobe (see few posts above) has the same issue with his HD5870. So it's not hardware specific, it's just software.

---

I use a 3850 AGP on WinXP32. (only to let ya know it is not 64bit only)

---

DSKAG Austria Research Team: http://www.research.dskag.at

... it's just software.

Exactly the point I have been trying to make for a couple of weeks. And exactly why I did the latest exercise just to prove it's not hardware.
Specifically, it's new MW@H tasks.
Older MW@H tasks worked fine on the same hardware & W7 64-bit:- see my earlier posts which explain it all.

I use a 3850 AGP on WinXP32. (only to let ya know it is not 64bit only).

dskagcommunity ... looking back on your posts they are different from the errors I got. Compare my working BOINC version/driver deails posted earlier with yours. Also worth checking that all .NET updates are, erm, up to date and flush old tasks then try the latest ... at various points in the past couple of weeks there have been a few false starts with generating new WU's that work.

Here is what i was referring to with the wattage fluctuations on 1.02 app. Is this normal and if so why?

Even with an app_info to try and control GPU% didn't help.

I use ATI Tray Tools rather than BOINC settings.
With ATI Tray Tools I can:-
a) set a custom fan profile (the fan profile in the standard driver had a major flaw)
b) set a custom VDDC (I'm currently running one HD3850 at 0.975V at full speed and a "problem", hot-running HD3850 at 1.014V) rather than the standard 1.254V
c) set the GPU & memory speeds (to +/- 2mhz. The "problem" HD3850 has a GPU speed set to 567mhz rather than the 669mhz standard & memory at full speed)
With ATI Tray tools set as above these cards do not exceed 55C at +/- 100% load, fan @ 60% max with lots of fresh, filtered airflow. OK, it's a cool summer here in the UK - overnight ambient 16.6C & breezy :-)

Why? Hot=inefficient=more current IIRC.
Sorry, no idea why 0.82 is better than 1.02 by 78W/0.65A @ 119V AC

So anyway ...

W7 64-bit/HD3850 AGP & existing MW@H GPU tasks ALL fail with "Computation error"
whereas ...
XP 32-bit/HD3850 AGP & existing MW@H GPU tasks work OK.
All SETI/Catalyst/etc the same on the same hardware.

What are your thoughts?

CPU version still failing on Linux/Ubuntu 12.04 using BOINC 7.0.28:
ps_separation_14_2s_05_3_test_1_1339497601_4215469_1

Stderr output
<core_client_version>7.0.28</core_client_version>
<![CDATA[
<message>
process exited with code 1 (0x1, -255)
</message>
<stderr_txt>
<search_application> milkyway_separation 1.00 Linux x86 double </search_application>
Unrecognized XML in project preferences: max_gfx_cpu_pct
Skipping: 50
Skipping: /max_gfx_cpu_pct
Unrecognized XML in project preferences: allow_non_preferred_apps
Skipping: 1
Skipping: /allow_non_preferred_apps
Error loading Lua script 'astronomy_parameters.txt': [string "argv = {...}..."]:1: arguments not set
Error reading astronomy parameters from file 'astronomy_parameters.txt'
Trying old parameters file
Error reading number_parameters
05:55:37 (7350): called boinc_finish

</stderr_txt>
]]>

---

I am currently getting no computational errors involving the work units. In fact I have not had a single error on a computational unit since the "test" series began.

I believe you have found the fix for the problem.

Dale

Just as update, Tried to upgrade to 7.0.25 but nothing changed to my "100% but no computing end" problem on MW *sign* seems i must continue to build/search a new opencl compatible mw system for wide under 100euro.

---

DSKAG Austria Research Team: http://www.research.dskag.at