And just when I thought I should fill up some Beta work before the server relocation, I find that I can not get any v7 ver 7.00 for my Hd7870. I've done thousands of 6.99, but maybe Eric haven't made the neccessary changes for us who are still running Boinc 6. Yeah well, such is life...

LOL

You can get lots of VLARs if you only ask for CPU work.

Claggy

Got my first 7.01 unit before "ye big blackout", unfortunately it errored out http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=13304405. Now I'm sort of idling (also using GPU power on WCG), waiting for more WUs. Are there any in the pipe?

Cheers!

---

Per aspera, ad astra!

Hmmm. Your machine should have been able to handle that. We'll see what happens to subsequent ones.

---

Hi Eric,

Unfortunately the second one suffered a similar fate. However, this one seems to have produced a much more interesting log: http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=13332995

I did notice something else that's strange: usually whenever I download Seti@Home and (I hope I'm not mistaking) Seti@Home Beta tasks, it takes a lot of attempts to actually get the 8MB package down bit by bit until it's all done. This time, I actually missed it. That's how fast it was...Maybe it's completely unrelated, but thought I'd mention it since I caught it.

Cheers!

---

Per aspera, ad astra!

There's more info there than the last one, at least.

---

My thoughts exactly. Hope that it will be sufficient for you to make sense of what's going on. Meanwhile I keep trying to get more work, but so far no luck.

By the way, regarding my comment about the download time...I don't know what you guys did, but I requested a new update on S@H and got 4 new tasks where I've seen speeds of over 600KB/s! :o I mean...WOW! I hope it's not just a fluke and that it will continue to be as fast from now on too. Anywho, I guess you can disregard that as a potential cause. One of those S@H WUs is crunching away as we speak and it has been for the past 15 minutes.

Cheers!

Edit: just got another 7.01. Also blazing fast to download. Waiting for the S@H Astropulse to finish and then I will report on how this one went.

---

Per aspera, ad astra!

Our new network connection should be able to handle about 5 times the bandwidth of the old one. We're currently running it at about half capacity.

---

Hats down to you, guys! Finally, SETI is getting some well-deserved resources! Keep up the good work!

Edit: got 2 more Betas lined up. I guess we'll soon know more about this.

Edit2: all 3 ended up in flames:
http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=13333271
http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=13333418
http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=13333420
Also, got another one in queue, but I think it's not going to be any different. Anyway, I will continue to crunch them as long as I get them. Let me know if there's anything else I can do to help.

---

Per aspera, ad astra!

Here are the hosts that have failed with this (Windows ATI OpenCL) app version.
46168
49935
51278
51691
54442
54535
55535
55574
55712
56715
56717
57006
57115
57926
58847
59178
59340
59685
59872
61179
61207
61618
61824
61911
61995
61999
62163
62236
62324
62595
62676
62687
62706
62758
62761
62806

Here are the hosts that have succeeded with this app version.
17552
45274
51535
51984
52691
53263
53486
54442
54829
55305
56375
56449
56560
56801
56893
57115
57289
58124
58133
58290
58405
58682
58712
58804
58879
58915
59378
59448
59919
60266
61288
61934
62163

Anyone see a common theme that I'm missing?

---

I'm guessing this isn't important but I'll post it anyway just in case.

I only have one little laptop so things are quite easy to monitor. It has completed around 18 valid v7.00_cuda32 tasks but none of them are showing up on the 'Application details' page.

http://setiweb.ssl.berkeley.edu/beta/host_app_versions.php?hostid=59090
http://setiweb.ssl.berkeley.edu/beta/results.php?hostid=59090&offset=0&show_names=0&state=4&appid=

Would be more interesting to know the used driver and OpenCL version of each of these hosts. From BOINCs description there seems to be no apparent reason for success or failure.

---

_\|/_
U r s

Biggest problem i see atm is lot of users changing drivers with driver deads kept on the system.
If anyone ran 13.2 beta or later the OpenCL compiler is broken.
Deinstall is not enough as i wrote at main already.
Posted a how to also weeks ago.
Even some guys with high skills dont even know which OpenCL version they are using.

Found 17 hosts already at main with non functioning OpenCL version.
PM`d them of course but who knows if they ever read it.

---

With each crime and every kindness we birth our future.

My ATI HD 7870 Error out on all 7.01's. Be that the 4 SETI@home v7 v7.01 (ati_opencl_sah), or the 30+ SETI@home v7 v7.01 (ati_opencl_pre129)

After reserching the error in the stderr file, here's the clue:

OpenCL-kernels filename : MultiBeam_Kernels_r1779.cl.

Of course it can't open that one. The downloaded .cl file is called MultiBeam_Kernels_r1779_windows.cl and not MultiBeam_Kernels_r1779.cl

Having renamed the MultiBeam_Kernels_r1779_windows.cl to what the app expects: MultiBeam_Kernels_r1779.cl, the newly downloaded WU's starts, and compiles the .bin files, and runs just fine. However, a new copy of the wrongly named MultiBeam_Kernels_r1779_windows.cl is also downloaded, but never touched of course by the app.

So, fix that naming error, and it should work just fine. Why some hosts get the wrongly named .cl file while others get the one named correctly, is another question for Eric to answer.

---

WARNING!! "THIS IS A SIGNATURE", of the "IT MAY CHANGE AT ANY MOMENT" type. It may, or may not be considered insulting, all depending upon HOW SENSITIVE THE VIEWER IS, to certain inputs to/from the nervous system.

Here's the first finished WU after having fixed the name error for the .cl file. The very first which includes the compiling info.


http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=13360274

---

WARNING!! "THIS IS A SIGNATURE", of the "IT MAY CHANGE AT ANY MOMENT" type. It may, or may not be considered insulting, all depending upon HOW SENSITIVE THE VIEWER IS, to certain inputs to/from the nervous system.

The 7.01 AMD/ATI app is working fine here, the difference here is i ran the AMD/ATI 7.00 app and the r1779 compilations were done then,

The app_version section tells Boinc to open the MultiBeam_Kernels_r1779_windows.cl file as MultiBeam_Kernels_r1779.cl, i suspect when the app tries to do its compilation and looks in the project directory it can't find MultiBeam_Kernels_r1779.cl (it's named different), so the Wu errors:


<file_ref>
<file_name>MultiBeam_Kernels_r1779_windows.cl</file_name>
<open_name>MultiBeam_Kernels_r1779.cl</open_name>
<copy_file/>
</file_ref>

I've reported the problem at Lunatics, looks as if we'll have to have different cl file names for Windows, Linux and OS X (and changes in the app so it uses the different file names).

Claggy

Why name of CL file was changed ?

Why name of CL file was changed ?

Because of:

Running an HD6870, but haven't managed to download a single WU so far, all error out, apparently because there's an issue with the:

3/27/2013 6:47:47 PM | SETI@home Beta Test | [error] File MultiBeam_Kernels_r1779.cl has wrong size: expected 113726, got 113874
3/27/2013 6:47:47 PM | SETI@home Beta Test | [error] Checksum or signature error for MultiBeam_Kernels_r1779.cl

Erm...help?

http://setiweb.ssl.berkeley.edu/beta/forum_thread.php?id=2008&postid=45361

Tried a direct download and it comes down as 113,874 bytes.

I'll check it out. Are you downloading the Windows or Linux version? I thought I had checked that both files were identical before adding the version. I need to add an overwrite check to update_versions.

<edit>
That was the problem. The opencl source in the linux version didn't match the windows version but they had the same filename. The linux version overwrote the windows version of the file which is causing the checksum errors.

Claggy

4618: driver: 1.4.1741 OpenCL: 1.02 (says nothis cause we don't use display driver we use OpenCL runtime); Host had 2 GPUs (Bart, Juniper) and was able to complete ATi AP. OpenCL RT at that time:
Driver version: 1084.4 (VM)
Version: OpenCL 1.2 AMD-APP (1084.4)
(and it's the only really relevant info about driver version. What BOINC reported can go to trash almost directly.
Example of failure on MB ATi:
<core_client_version>7.0.44</core_client_version>
<![CDATA[
<message>
- exit code -1073741819 (0xc0000005)
</message>
<stderr_txt>

</stderr_txt>
]]>

I don't see any OpenCL-related stuff here. App just did not print ANYTHING to stderr and in reality it puts some info long before first OpenCL API call.
I would say not OpenCL-related issue.


49935:
[2] AMD AMD Radeon HD 6900 series (Cayman) (2048MB) driver: 1.4.1741 OpenCL: 1.02 (again 2 GPUs in host, it's common)
core_client_version>7.0.47</core_client_version>
<![CDATA[
<message>
- exit code -1073741819 (0xc0000005)
</message>
<stderr_txt>
Running on device number: 1
Priority of worker thread raised successfully
Priority of process adjusted successfully, below normal priority class used
OpenCL platform detected: Advanced Micro Devices, Inc.
BOINC assigns device 1
Info: BOINC provided device ID used

Build features: SETI7 Non-graphics OpenCL USE_OPENCL_HD5xxx OCL_ZERO_COPY OCL_CHIRP3 FFTW AMD specific USE_SSE x86
CPUID: AMD Phenom(tm) II X6 1090T Processor

Cache: L1=64K L2=512K

CPU features: FPU TSC PAE CMPXCHG8B APIC SYSENTER MTRR CMOV/CCMP MMX FXSAVE/FXRSTOR SSE SSE2 HT SSE3
OpenCL-kernels filename : MultiBeam_Kernels_r1779.cl
INFO: can't open binary kernel file: C:\ProgramData\BOINC/projects/setiweb.ssl.berkeley.edu_beta\MultiBeam_Kernels_r1779.clHD5_Cypress.bin_V7, continue with recompile...


Unhandled Exception Detected...

- Unhandled Exception Record -
Reason: Access Violation (0xc0000005) at address 0x004220A7 read attempt to address 0x00000000

Engaging BOINC Windows Runtime Debugger...

Now error at compilation. Perhaps, home-made issue when CL file was changed w/o asking if it's possible.

I think no sense to check other hosts cause file renaming issue most probable explanation of errors currently.

Anyone see a common theme that I'm missing?

Those hosts who has binary cache already were able to continue working. Other failed.

Why name of CL file was changed ?

Because of:

Running an HD6870, but haven't managed to download a single WU so far, all error out, apparently because there's an issue with the:

3/27/2013 6:47:47 PM | SETI@home Beta Test | [error] File MultiBeam_Kernels_r1779.cl has wrong size: expected 113726, got 113874
3/27/2013 6:47:47 PM | SETI@home Beta Test | [error] Checksum or signature error for MultiBeam_Kernels_r1779.cl

Erm...help?

http://setiweb.ssl.berkeley.edu/beta/forum_thread.php?id=2008&postid=45361

Tried a direct download and it comes down as 113,874 bytes.

I'll check it out. Are you downloading the Windows or Linux version? I thought I had checked that both files were identical before adding the version. I need to add an overwrite check to update_versions.

<edit>
That was the problem. The opencl source in the linux version didn't match the windows version but they had the same filename. The linux version overwrote the windows version of the file which is causing the checksum errors.

Claggy

Maybe it was worth to binary compare files, check if Linux can work with already release Windows CL file offlien (I'm almost sure that it can) and release Linux app with correct CL file then?
Such sequence solve many tasks from crashing and many users from wondering what happened with prev worked app.

CL file is text file so most probably Urs' SVN converted it to Linux-style of carriage return (truncated one with only 1 byte instead of 2). This Linux-style causes so many troubles when Linux-made txt file opened in Windows notepad for example... Here the reason the same <CR><LF> truncated.

The linux version overwrote the windows version of the file which is causing the checksum errors.

Never heard about files overwriting themselves. Usually it made by operator ;)