Report problems by commenting to this post.

---

Checking wingmates, I notice that user CElliott has several computers with long turnround times, still with a significant number of v6.98/v6.99 tasks in progress. In two cases (hosts 52900 and 58772), those older applications are installed under anonymous platform. Given your urgency in getting these final validation tests completed so that you can transfer the new v7.00 apps to Main, is there any way you could get a message to CElliott and encourage him to devote his considerable and welcome resources to the new effort?

I'll drop him a line.

---

Checking wingmates again, host 62650 is an interesting one to watch. It has a full set of ATI, NVIDIA, and INTEL GPUs.

Unfortunately, it also has a tendency to return completely blank stderr_txt sections: the opencl_ati_sah application also has a tendency to return inconclusive results after a suspiciously short time. But without stderr, we can't see what it overflowed on.

Edit - host 56716 seems to be going the same way with the CPU app - first time I've ever seen that.

Checking wingmates again, host 62650 is an interesting one to watch. It has a full set of ATI, NVIDIA, and INTEL GPUs.

Unfortunately, it also has a tendency to return completely blank stderr_txt sections: the opencl_ati_sah application also has a tendency to return inconclusive results after a suspiciously short time. But without stderr, we can't see what it overflowed on.

Edit - host 56716 seems to be going the same way with the CPU app - first time I've ever seen that.

I've seen it a few times on other hosts running stock CPU applications, and Matt Arsenault's "stderr returned unreliable" thread on boinc_dev in January 2012 was related to cases at Milkyway@home. I liked his proposed change on general principles, although it might not have fixed the problem it was clean and simple and IMO very unlikely to have any bad side effects. It might be worth asking if Milkyway implemented the change even though David rejected it.

                                                                  Joe

All v7 7 running clear on both laptop and the ati and nvada

Only these two to report as inconclusive


WU 4990049

WU 4990042

Michael

64bit Linux app still using old fftw-lib :

fftw-3.1.1a fftwf_wisdom

that way no avx-support for codelets. Actual version is 3.3.x

---

_\|/_
U r s

That's weird. I installed fftw-3.3.3 on the machine I compiled on. There must still be a copy of the old library hanging around somewhere.

---

32bit Linux app also shows the same issue with the old fftw-lib.

---

_\|/_
U r s

That is odd 3.1.1a isn't even installed on the 32-bit build machine never has been.

---

Another inconclusive with matching number of signals :
WU 4994675

---

_\|/_
U r s

Another inconclusive with matching number of signals :
WU 4994675

save workunit offline and rerun with -v 2 option

Another inconclusive with matching number of signals :
WU 4994675

save workunit offline and rerun with -v 2 option

Stock cpu app has a -v 2 option ?

Another inconclusive where opencl_ati has 3 pulses less than stock :
WU 4996577

---

_\|/_
U r s

Another inconclusive where opencl_ati has 3 pulses less than stock :
WU 4996577

Yep, that AMD user is running Cat 12.10/APP runtime 1016.4, so that is expected, he'll continue producing inconclusives until:

a) he downgrades to Cat 12.8/938.2 or earlier, deletes his old compilations and redoes them. (requires user to do it)
b) he upgrades to a later driver, and Eric releases a fresh app that does fresh compilations. (requires min and max driver versions to be set for sending out AMD/ATI work, and requires a different revision app):

  Name:						 Juniper
  Vendor:					 Advanced Micro Devices, Inc.
  Driver version:				 1016.4 (VM)
  Version:					 OpenCL 1.2 AMD-APP (1016.4)
  Extensions:					 cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics
                                                 cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics
                                                 cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_gl_sharing
                                                 cl_ext_atomic_counters_32 cl_amd_device_attribute_query cl_amd_vec3
                                                 cl_amd_printf cl_amd_media_ops cl_amd_popcnt cl_khr_d3d10_sharing
                                                 cl_khr_dx9_media_sharing 

Claggy

Another inconclusive with matching number of signals :
WU 4994675

save workunit offline and rerun with -v 2 option

Stock cpu app has a -v 2 option ?

Another inconclusive where opencl_ati has 3 pulses less than stock :
WU 4996577

there was GPU app involved

Four more inconclusive CPU/GPU Host 62767/61742



WU 4944788

WU 4944787

WU 4944786

WU 4944785 Pulse count different

Michael

For what reason all with outdated ATi app ?

Something screwy happening here. The latest batch are causing my ATI graphics drivers to fail and restart, but will no longer process the work units. This seems to only be affecting my Windows 8 (64 bit) computer with 16 gigs of ram and an ATI 7950 card.
My older computer with windows 7 (64 bit) but running the same ATI drivers with a HD 5800 graphics card and only 4 gigs of ram seems to be processing them fine.

I have had to suspend the project as despite it no actually processing the units, it won't allow other projects to use the GPU.

Something screwy happening here. The latest batch are causing my ATI graphics drivers to fail and restart, but will no longer process the work units. This seems to only be affecting my Windows 8 (64 bit) computer with 16 gigs of ram and an ATI 7950 card.
My older computer with windows 7 (64 bit) but running the same ATI drivers with a HD 5800 graphics card and only 4 gigs of ram seems to be processing them fine.

I have had to suspend the project as despite it no actually processing the units, it won't allow other projects to use the GPU.

1) What driver at least ??? :/
2) Os difference may be not as important as difference in GPU itself. HD7950 vs HD58xx (what xx is btw? ). Different GPU architecture (and it's really different between these 2) incurs different paths in driver and different ISAs from compiler.

3)
HD58xx OpenCL 1.2 AMD-APP (1084.4)
HD7xxx OpenCL 1.2 AMD-APP (1016.4)

I would not call these 2 "same driver"...

4)from Claggy's post above"

Cat 12.10/APP runtime 1016.4

So I would not expect too good results from HD7xxx host even w/o driver restarts...

I've released 7.01 from Linux i686 and x86_64. The only difference it that the proper FFTW (3.3.3) libraries are linked in.

---