Someone should been able to grab this 1, Workunit 2301590234, as it's still in progress.

Cheers.

I have also saved this file to Google Drive
https://drive.google.com/file/d/0B0-3oeXJF8g0Y3lVYnJ0ZU9WS0U/view?usp=sharing

Unfortunately I did not get the other file

I've also got a new quadruple in my own list this evening.

Workunit 2301658991 (blc3_2bit_guppi_57432_25217_HIP57328_0003.31678.831.18.27.117.vlar)
Task 5234418931 (S=6, A=0, P=13, T=11, G=0) SSE3xj Win32 Build 3528
Task 5234418932 (S=10, A=0, P=10, T=10, G=0) v8.00 windows_intelx86
Task 5236649323 (S=10, A=0, P=10, T=10, G=0) x41p_zi3k, Cuda 8.00 special
Task 5237476192 (S=1, A=25, P=1, T=3, G=0) v8.03 x86_64-apple-darwin

Since the 5th host that got this WU ran it as stock Windows CPU, it shouldn't come as a surprise that its results matched the 2nd host and the WU is now validated. However, only 4 of the 5 hosts got credit. The Mac result was declared Invalid, which seems to be fairly common for that host.

Now, since a new quadruple Inconclusive for a late stage overflow seems to be almost a daily occurrence, he's my new one for this evening, 3 SoG r3528 machines and one stock Windows app, all with different counts. The 5th host will again be a stock Windows app, so it should match with the 3rd host.

Workunit 2301105316 (08ja09ab.7925.16428.8.35.187)
Task 5233243565 (S=16, A=7, P=6, T=1, G=0) v8.19 (opencl_nvidia_SoG) windows_intelx86
Task 5233243566 (S=17, A=7, P=5, T=1, G=0) v8.19 (opencl_nvidia_SoG) windows_intelx86
Task 5234773670 (S=21, A=7, P=2, T=0, G=0) v8.00 windows_intelx86
Task 5236410759 (S=20, A=7, P=3, T=0, G=0) SSE3xj Win32 Build 3528

Grabbed the unit in question
Saved to Google Drive: https://drive.google.com/file/d/0B0-3oeXJF8g0ejF0VEtRV19XTDA/view?usp=sharing

Grabbed the unit in question
Saved to Google Drive: https://drive.google.com/file/d/0B0-3oeXJF8g0ejF0VEtRV19XTDA/view?usp=sharing

Hi,

I ran this WU with my computer with the linux CPU executable and my current development version ...

Current WU: 08ja09ab.7925.16428.8.35.187.wu

----------------------------------------------------------------
Running default app with command :... setiathome_8.04_i686-pc-linux-gnu
Elapsed Time: ....................... 2444 seconds

----------------------------------------------------------------
Running app with command : .......... axo -bs -pfb 8 -pfp 120 -unroll 20 --device 1
gCudaDevProps.multiProcessorCount = 20
Work data buffer for fft results size = 320864256
MallocHost G=33554432 T=33554432 P=16777216 (16)
MallocHost tmp_PoTP=16777216
MallocHost tmp_PoTP2=16777216
MallocHost tmp_PoTT=16777216
MallocHost tmp_PoTG=12582912
MallocHost best_PoTP=16777216
MallocHost bestPoTG=12582912
Allocing tmp data buf for unroll 20
MallocHost tmp_smallPoT=524288
MallocHost PowerSpectrumSumMax=3145728
GPSF 3.035655 3 5.352018
AcIn 16779264 AcOut 33558528
Mallocing blockSums 24576 bytes
Elapsed Time : ...................... 115 seconds
Speed compared to default : ......... 2125 %
-----------------
Comparing results
Result      : Strongly similar,  Q= 99.93%

----------------------------------------------------------------
Done with 08ja09ab.7925.16428.8.35.187.wu

... and the rescmpv5_l says with Q100 option ...

root@Linux1:~/KWSN-Bench-Linux-MBv7_v2.01.08# ./rescmpv5_l  testData/ref-result.setiathome_8.04_i686-pc-linux-gnu.08ja09ab.7925.16428.8.35.187.wu.sah testData/result.axo.08ja09ab.7925.16428.8.35.187.wu.sah Q100
                ------------- R1:R2 ------------     ------------- R2:R1 ------------
                Exact  Super  Tight  Good    Bad     Exact  Super  Tight  Good    Bad
        Spike      0     21     21     21      0        0     21     21     21      0
     Autocorr      0      7      7      7      0        0      7      7      7      0
     Gaussian      0      0      0      0      0        0      0      0      0      0
        Pulse      0      2      2      2      0        0      2      2      2      0
      Triplet      0      0      0      0      0        0      0      0      0      0
   Best Spike      0      0      0      0      0        0      0      0      0      0
Best Autocorr      0      0      0      0      0        0      0      0      0      0
Best Gaussian      0      0      0      0      0        0      0      0      0      0
   Best Pulse      0      0      0      0      0        0      0      0      0      0
 Best Triplet      0      0      0      0      0        0      0      0      0      0
                ----   ----   ----   ----   ----     ----   ----   ----   ----   ----
                   0     30     30     30      0        0     30     30     30      0

Result      : Strongly similar,  Q= 99.93%

---

To overcome Heisenbergs:
"You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones

Well, I don't know if there's anything further that can be learned from these, but...another day, another quadruple Inconclusive, so I'll go ahead and post it. This one appears to be more of the "Instant" overflow variety.

Workunit 2303805767 (20jl16aa.1361.42541.16.43.252)
Task 5239013701 (S=28, A=2, P=0, T=0, G=0) SSE3xj Win32 Build 3528
Task 5239013702 (S=29, A=1, P=0, T=0, G=0) v8.00 windows_intelx86
Task 5241134325 (S=30, A=0, P=0, T=0, G=0) v8.00 (cuda42) windows_intelx86
Task 5241657014 (S=30, A=0, P=0, T=0, G=0) x41p_zi3i, Cuda 7.50 special

Tbar, the last one appears to be one of yours. The good news, I suppose, is that it only took about 5 seconds to join the party. :^)

EDIT: Looks like this WU file is gone already, even though at the time of this posting the WU page shows that it's still in progress on the 5th host. I guess the Replica DB hasn't quite caught up from the outage yet. Sorry about that.

An Instant Overflow. Nothing strange here. This has been a problem for as long as I remember. It wasn't unusual to see these go through a full 10 Hosts and still not validate. Only taking 5 is an improvement. The Special App definitely doesn't care for them, look through the Top Linux Hosts and you will see them Full of Instant Overflow Inconclusives. My Mac is actually on the low side. I'd try a newer build, but zi3i is the last version I have.

It is frustrating when you get a noisy WU, and you don't agree with your wingmen what goes where.

My Invalid
Spike count: 7
Autocorr count: 2
Pulse count: 6
Triplet count: 16
Gaussian count: 0


Them
Spike count: 18
Autocorr count: 11
Pulse count: 1
Triplet count: 0
Gaussian count: 0


Spike count: 18
Autocorr count: 11
Pulse count: 1
Triplet count: 0
Gaussian count: 0

blc3_2bit_guppi_57432_27585_HIP57494_OFF_0010.31802.0.17.26.8.vlar

---

Grant
Darwin NT

blc3_2bit_guppi_57432_27585_HIP57494_OFF_0010.31802.0.17.26.8.vlar

It's too late to catch the datafile for this one, but the two 18-11 results were from:

Stock v8.03 x86_64-apple-darwin
Stock v8.00 x86_64-pc-linux-gnu

It's about time we swung the microscope over to them.

blc3_2bit_guppi_57432_27585_HIP57494_OFF_0010.31802.0.17.26.8.vlar

It's too late to catch the datafile for this one, but the two 18-11 results were from:

Stock v8.03 x86_64-apple-darwin
Stock v8.00 x86_64-pc-linux-gnu

It's about time we swung the microscope over to them.

Would setting up a hackintosh be a 'good' enough solution? Since I am sure we don't want to spend money on a mac for debugging

blc3_2bit_guppi_57432_27585_HIP57494_OFF_0010.31802.0.17.26.8.vlar

It's too late to catch the datafile for this one, but the two 18-11 results were from:

Stock v8.03 x86_64-apple-darwin
Stock v8.00 x86_64-pc-linux-gnu

It's about time we swung the microscope over to them.

From the list I generated for my hosts last evening:
v8.03 x86_64-apple-darwin
Workunit 2297635785 (19ja09ab.20199.22976.7.34.9)
Task 5225887776 (S=24, A=6, P=0, T=0, G=0) v8.03 x86_64-apple-darwin
Task 5225887777 (S=22, A=8, P=0, T=0, G=0) SSE3xj Win32 Build 3528

Workunit 2298286244 (blc3_2bit_guppi_57451_20612_HIP62472_0007.24494.416.18.27.181.vlar)
Task 5227261751 (S=19, A=1, P=10, T=0, G=0) SSE3xj Win32 Build 3528
Task 5227261752 (S=20, A=1, P=9, T=0, G=0) SSE3xj Win32 Build 3500
Task 5229822975 (S=21, A=1, P=8, T=0, G=0) v8.03 x86_64-apple-darwin

Workunit 2299858620 (blc3_2bit_guppi_57451_22465_HIP63121_OFF_0012.23004.0.18.27.235.vlar)
Task 5230589212 (S=24, A=1, P=5, T=0, G=0) SSE3xj Win32 Build 3528
Task 5231099938 (S=25, A=1, P=4, T=0, G=0) v8.03 x86_64-apple-darwin

Workunit 2306647376 (10jl16ab.6877.93530.12.39.148)
Task 5245051755 (S=0, A=1, P=0, T=3, G=1) v8.19 (opencl_intel_gpu_sah) windows_intelx86
Task 5245051756 (S=0, A=1, P=0, T=13, G=0) v8.03 x86_64-apple-darwin

v8.00 x86_64-pc-linux-gnu
Workunit 2293324473 (15mr09ad.13715.17659.14.41.108)
Task 5216731859 (S=8, A=0, P=0, T=0, G=3) v8.19 (opencl_intel_gpu_sah) windows_intelx86
Task 5216731860 (S=8, A=0, P=0, T=0, G=2) v8.00 x86_64-pc-linux-gnu

Workunit 2298108679 (24dc09aa.2403.24198.5.32.10)
Task 5226886598 (S=23, A=7, P=0, T=0, G=0) v8.00 x86_64-pc-linux-gnu
Task 5226886599 (S=22, A=8, P=0, T=0, G=0) SSE3xj Win32 Build 3528

Workunit 2300494353 (19jl16aa.19093.174068.12.39.135)
Task 5231941244 (S=2, A=0, P=3, T=0, G=1) v8.00 x86_64-pc-linux-gnu
Task 5231941245 (S=2, A=0, P=2, T=0, G=1) v8.00 (opencl_intel_gpu_sah) x86_64-apple-darwin

I refrained from posting this one when it was just a quadruple, a couple days ago, but now that it's become a quintuple Inconclusive, I think it merits some publicity.

Workunit 2304111745 (blc3_2bit_guppi_57432_27257_HIP57494_0009.15810.831.18.27.104.vlar)
Task 5239674006 (S=20, A=0, P=10, T=0, G=0) SSE3xj Win32 Build 3528
Task 5239674007 (S=18, A=0, P=12, T=0, G=0) v8.19 (opencl_nvidia_SoG) windows_intelx86
Task 5242168321 (S=20, A=0, P=10, T=0, G=0) v8.19 (opencl_nvidia_SoG) windows_intelx86
Task 5244395277 (S=19, A=0, P=11, T=0, G=0) v8.19 (opencl_nvidia_SoG) windows_intelx86
Task 5245993619 (S=21, A=0, P=9, T=0, G=0) SSE2xj Win32 Build 3500

The sixth host looks like it will be running stock Windows CPU.

I refrained from posting this one when it was just a quadruple, a couple days ago, but now that it's become a quintuple Inconclusive, I think it merits some publicity.

Workunit 2304111745 (blc3_2bit_guppi_57432_27257_HIP57494_0009.15810.831.18.27.104.vlar)
Task 5239674006 (S=20, A=0, P=10, T=0, G=0) SSE3xj Win32 Build 3528
Task 5239674007 (S=18, A=0, P=12, T=0, G=0) v8.19 (opencl_nvidia_SoG) windows_intelx86
Task 5242168321 (S=20, A=0, P=10, T=0, G=0) v8.19 (opencl_nvidia_SoG) windows_intelx86
Task 5244395277 (S=19, A=0, P=11, T=0, G=0) v8.19 (opencl_nvidia_SoG) windows_intelx86
Task 5245993619 (S=21, A=0, P=9, T=0, G=0) SSE2xj Win32 Build 3500

The sixth host looks like it will be running stock Windows CPU.

I have downloaded and uploaded this file to my Google Drive.
I will also try to run it using to apps, that may give inconclusive:
https://drive.google.com/file/d/0B0-3oeXJF8g0WW1qQTlaaFE2dzA/view?usp=sharing

I refrained from posting this one when it was just a quadruple, a couple days ago, but now that it's become a quintuple Inconclusive, I think it merits some publicity.

Workunit 2304111745 (blc3_2bit_guppi_57432_27257_HIP57494_0009.15810.831.18.27.104.vlar)
Task 5239674006 (S=20, A=0, P=10, T=0, G=0) SSE3xj Win32 Build 3528
Task 5239674007 (S=18, A=0, P=12, T=0, G=0) v8.19 (opencl_nvidia_SoG) windows_intelx86
Task 5242168321 (S=20, A=0, P=10, T=0, G=0) v8.19 (opencl_nvidia_SoG) windows_intelx86
Task 5244395277 (S=19, A=0, P=11, T=0, G=0) v8.19 (opencl_nvidia_SoG) windows_intelx86
Task 5245993619 (S=21, A=0, P=9, T=0, G=0) SSE2xj Win32 Build 3500

The sixth host looks like it will be running stock Windows CPU.

The interesting thing about that WU is that the first four tasks all used exactly the same application - NV SoG r3528.

Jeff has his anonymous platform deployment tuned up with a command line, but the other three are all operating in default mode. And there's not a great deal of difference in the GPUs either - GTXs 960, 980, 760, 760 Ti OEM respectively. I'm getting a hint of overclocking from the 980 (Max clock 1367Mhz feels a bit toasty, and it has a previous invalid) - but why can't the other three come up with a matched pair between them?

blc3_2bit_guppi_57432_27585_HIP57494_OFF_0010.31802.0.17.26.8.vlar

It's too late to catch the datafile for this one, but the two 18-11 results were from:

Stock v8.03 x86_64-apple-darwin
Stock v8.00 x86_64-pc-linux-gnu

It's about time we swung the microscope over to them.

Would setting up a hackintosh be a 'good' enough solution? Since I am sure we don't want to spend money on a mac for debugging

By itself, that wouldn't help us much. Judging by the deployment dates (7 Jan 2016 and 30 Dec 2015 respectively), both those apps were developed in the labs at Berkeley: it's really a question of persuading whoever has 'ownership' of those two builds (I suspect our Eric K did the codebase and probably the Linux build: Charlie Fenton probably did the Mac build from Eric's code) to revisit their past and review their work. Unless somebody here has the skill to replicate their work under laboratory conditions (i.e. using the same OS version, build tools and settings), and work out where they went wrong, I don't think that simply running more tests is going to move us forward.

I described why same SoG revision will give different set of signals on overflow even on similar (not speaking about different) hardware earlier. When/if SoG transformation will be completed this effect will be eliminated.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

I described why same SoG revision will give different set of signals on overflow even on similar (not speaking about different) hardware earlier. When/if SoG transformation will be completed this effect will be eliminated.

Ah, yes - I think I have a vague memory of that. Wasn't it something like 'this is a SSoG build' - "Some Signals on GPU"? Any ideas on the timeline for a fully-finished build?

"After SoG TwinChirp" - that's all I could say about timeline.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

"After SoG TwinChirp" - that's all I could say about timeline.

Any idea on an updated OSX build? I decided to run the latest System updates and that caused me to have to install new nVidia graphics drivers. So, while I had the GTS 250 in the machine I booted to Mavericks and compiled the Apps there. Same results as with the Apps compiled in El Capitan, the Intel build is about normal whereas the NV & NV-SoG builds took much longer to finish and crashed frequently with the BLC tasks. I still haven't heard a word on how the Intel Build works on a real iGPU.

"After SoG TwinChirp" - that's all I could say about timeline.

Any idea on an updated OSX build? I decided to run the latest System updates and that caused me to have to install new nVidia graphics drivers. So, while I had the GTS 250 in the machine I booted to Mavericks and compiled the Apps there. Same results as with the Apps compiled in El Capitan, the Intel build is about normal whereas the NV & NV-SoG builds took much longer to finish and crashed frequently with the BLC tasks. I still haven't heard a word on how the Intel Build works on a real iGPU.

All I could do is to make NV path equal to iGPU one for OS X.
W/o target hardware hard to do any serious debugging.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

All I could do is to make NV path equal to iGPU one for OS X.
W/o target hardware hard to do any serious debugging.

Well, it looks as though the Intel Path is the only one that works on my machine. Even the App using just "Build features: SETI8 Non-graphics OpenCL OCL_CHIRP3 ASYNC_SPIKE FFTW SSSE3 64bit" crashes on both types of tasks. The BLC6 got most of the way through and the reference_work_unit_r3215 crashed about half way with the Same Error.

Triplet: peak=8.657347, time=80.39, period=0.5439, d_freq=1418924863.12, chirp=0.91687, fft_len=128
Spike: peak=22.39685, time=100.7, d_freq=1418919461.29, chirp=1.0592, fft_len=128k
Spike: peak=22.54006, time=100.7, d_freq=1418919461.29, chirp=1.0629, fft_len=128k
Spike: peak=22.37677, time=33.55, d_freq=1418917201.18, chirp=2.3476, fft_len=128k
Spike: peak=22.37098, time=95.63, d_freq=1418924030.24, chirp=2.7506, fft_len=32k
Spike: peak=22.42656, time=95.63, d_freq=1418924030.23, chirp=2.8097, fft_len=32k
MBv8_8.18r3550_OpenCL_ssse3_x86_64-apple-darwin(21902,0x700000122000) malloc: *** error for object 0x1140bb000: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
SIGABRT: abort called

Crashed executable name: MBv8_8.18r3550_OpenCL_ssse3_x86_64-apple-darwin
Machine type Intel 80486 (64-bit executable)
System version: Macintosh OS 10.11.6 build 15G1108
Sat Oct 29 15:41:58 2016

Google says;
Result: ruby(28425,0x7fff70bc9ca0) malloc: *** error for object 0x100400000: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
https://bugs.ruby-lang.org/issues/4389
This issue was solved with changeset r30840

The only one that doesn't crash is the Intel build.