HueHueHueHueHueHueHue

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

I eagerly await the rollout of the latest SoG and Intel GPU apps to full production status.

The bigger beta participation will be the sooner they will appear on main.
Eric placed them on beta already:
Windows/x86 8.20 (opencl_ati5_sah) 8 Nov 2016, 23:03:25 UTC 0 GigaFLOPS
Windows/x86 8.20 (opencl_intel_gpu_sah) 25 Oct 2016, 18:46:05 UTC 175 GigaFLOPS
Windows/x86 8.20 (opencl_nvidia_SoG) 8 Nov 2016, 23:03:25 UTC 255 GigaFLOPS

BTW, did you test v8.20 SoG vs CPU validation offline for that unfortunate task?
Would be interesting to see if 8.20 could help there.

---

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

I eagerly await the rollout of the latest SoG and Intel GPU apps to full production status.

The bigger beta participation will be the sooner they will appear on main.
Eric placed them on beta already:
Windows/x86 8.20 (opencl_ati5_sah) 8 Nov 2016, 23:03:25 UTC 0 GigaFLOPS
Windows/x86 8.20 (opencl_intel_gpu_sah) 25 Oct 2016, 18:46:05 UTC 175 GigaFLOPS
Windows/x86 8.20 (opencl_nvidia_SoG) 8 Nov 2016, 23:03:25 UTC 255 GigaFLOPS

Okay, I'll switch my multi-GPU boxes over to Beta as soon as this surprise maintenance period is over. That will add 11 NVIDIA GPUs to the mix. Can't help with the ATI and Intel, though.

BTW, did you test v8.20 SoG vs CPU validation offline for that unfortunate task?
Would be interesting to see if 8.20 could help there.

No, I didn't. However, so far I haven't seen a single instance on my machines where r3556 didn't agree with stock CPU, so I feel comfortable that it would have matched up here, as well. If anyone would like to run an offline test with it, though, I've uploaded the WU file to my Amazon cloud drive as WU226235680.zip.

Got it, thanks.
Will check with ATi SoGs.

---

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

Copying from the installer thread:

http://setiathome.berkeley.edu/workunit.php?wuid=2320732915
http://boinc2.ssl.berkeley.edu/sah/download_fanout/11d/20ja09ae.12842.7843.8.35.202

Looks like it's the pulses again.

(opencl_intel_gpu_sah) x86_64-apple-darwin
Best pulse: peak=6.931435 , time=96.44, period=2.586 , d_freq=1419474418.49, score=0.9659, chirp=-25.435, fft_len=512

r3557 SoG
Best pulse: peak=0.9932134, time=11.99, period=0.1532, d_freq=1419474804.37, score=0.9999, chirp= 71.006, fft_len=128

Although both are below the reporting threshhold, they're wildly different.

That v8.00 (opencl_intel_gpu_sah) x86_64-apple-darwin shows up quite a lot in the Inconclusive lists I've been generating for my hosts. For example:

Workunit 2320911573 (22mr09ab.23966.2117.9.36.85)
Task 5275155431 (S=0, A=1, P=0, T=0, G=0) v8.00 (opencl_intel_gpu_sah) x86_64-apple-darwin
Task 5275155432 (S=0, A=1, P=1, T=0, G=0) SSE3xj Win32 Build 3556

The corresponding best pulses are:
Best pulse: peak=7.604383, time=12.96, period=2.615, d_freq=1420828933.46, score=0.9786, chirp=29.416, fft_len=64
Best pulse: peak=3.731792, time=25.91, period=1.106, d_freq=1420833535.84, score=1.022, chirp=30.395, fft_len=128

I've generally been ignoring all the Intel GPUs showing up on my list, and now that there's a new version over on Beta, v8.19, I wonder if it's worth paying attention to these here on Main at all.

To save time i would recommend to concentrate on proven valid versus currently in testing and omit proven imprecise.
Proven imprecise are imprecise indeed and onyl fix for this - to speedup testing and release of new builds.
v8.00 (opencl_intel_gpu_sah) x86_64-apple-darwin is proven imprecise.
(that's why we have new TBar's binaries on beta few days already)

---

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

As I already wrote on beta, would be good to put additional CPU processing with proved apps back to beta for some time.
To increase number of valid reference results for testing new builds.

---

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

Both my AMD A10-6700 in Windows 10 and Opteron 1210 in Linux-64 are crunching SETI Beta tasks.
Tullio

---

No, I didn't. However, so far I haven't seen a single instance on my machines where r3556 didn't agree with stock CPU, so I feel comfortable that it would have matched up here, as well. If anyone would like to run an offline test with it, though, I've uploaded the WU file to my Amazon cloud drive as WU226235680.zip.

And offline results:

MB8_win_x86_SSE2_OpenCL_ATi_HD5_r3330.exe  / blc4_2bit_guppi_57449_42556_HIP78775_0009.14621.416.18.27.57.vlar.wu : 
R2: .\ref\ref-MB8_win_x86_SSE3_VS2008_r3330.exe-blc4_2bit_guppi_57449_42556_HIP78775_0009.14621.416.18.27.57.vlar.wu.res 
Result      : Strongly similar,  Q= 99.58%

setiathome_8.19_windows_intelx86__opencl_ati5_sah.exe  / blc4_2bit_guppi_57449_42556_HIP78775_0009.14621.416.18.27.57.vlar.wu : 
R2: .\ref\ref-MB8_win_x86_SSE3_VS2008_r3330.exe-blc4_2bit_guppi_57449_42556_HIP78775_0009.14621.416.18.27.57.vlar.wu.res 
                ------------- R1:R2 ------------     ------------- R2:R1 ------------
                Exact  Super  Tight  Good    Bad     Exact  Super  Tight  Good    Bad
        Spike      0      1      1      1      0        0      1      1      1     24
     Gaussian      0      0      0      0      0        0      0      0      0      0
        Pulse      0      5      5      5     25        0      5      5      5      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 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      6      6      6     25        0      6      6      6     24

Unmatched signal(s) in R1 at line(s) 473 500 527 553 579 605 632 659 687 713 740 768 795 822 849 876 903 930 958 985 1011 1037 1065 1091 1118
Unmatched signal(s) in R2 at line(s) 409 425 467 483 499 515 531 547 563 606 649 665 681 697 713 729 745 761 777 793 809 825 841 857
For R1:R2 matched signals only, Q= 99.80%
Result      : Different.

setiathome_8.20_windows_intelx86__opencl_ati5_sah.exe  / blc4_2bit_guppi_57449_42556_HIP78775_0009.14621.416.18.27.57.vlar.wu : 
R2: .\ref\ref-MB8_win_x86_SSE3_VS2008_r3330.exe-blc4_2bit_guppi_57449_42556_HIP78775_0009.14621.416.18.27.57.vlar.wu.res 
Result      : Strongly similar,  Q= 99.58%

So yes, 8.20 should process such tasks w/o inconclusives.

---

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

Way back on 29 Sep, in Message 1820375, I posted the first quadruple Inconclusive that I had run across on one of my machines. Finally, after the original potential tiebreaker host timed out, another host just finished running that WU, and guess what, we have another quintuple Inconclusive.

Workunit 2267687414 (blc4_2bit_guppi_57403_HIP11048_0004.3489.0.22.45.87.vlar)
Task 5162535378 (S=17, A=0, P=12, T=1, G=0) v8.12 (opencl_nvidia_SoG) windows_intelx86
Task 5162535379 (S=19, A=0, P=10, T=1, G=0) v8.00 windows_intelx86
Task 5164467009 (S=10, A=0, P=19, T=1, G=0) SSE3xj Win32 Build 3500
Task 5167802793 (S=15, A=0, P=14, T=1, G=0) v8.12 (opencl_nvidia_SoG) windows_intelx86
Task 5286353178 (S=6, A=0, P=23, T=1, G=0) v8.19 (opencl_nvidia_SoG) windows_intelx86

Unfortunately, it's now gone out to another host running SoG r3528, so I guess it's a tossup as to whether it will validate or whether the scheduler will finally give up on this WU. :^)

Just for the record and future reference, the final host did actually validate against the other SoG r3528 with counts of (S=6, A=0, P=23, T=1, G=0). That means that Task 5286353178 was anointed as the canonical result, with counts that are significantly different than the "gold standard" stock Windows CPU app. So it goes.

Hopefully v8.20 SoG will be here soon and most of these sorts of messes will go away.

I think this WU is the first one I've noticed where one of my r3556 tasks got an Inconclusive against what appears to be a stable stock Windows host. The signal counts match, though, so it must be something subtle.

Workunit 2332864190 (21fe09ab.7357.18068.5.32.196)
Task 5300443647 (S=10, A=0, P=6, T=1, G=1) SSE3xj Win32 Build 3556
Task 5300443648 (S=10, A=0, P=6, T=1, G=1) v8.00 windows_intelx86

Here's a (possibly) interesting inconclusive between my OpenCL r3557 and Petri33's "x41p_zi3k, Cuda 8.00 special".

---

Here's a (possibly) interesting inconclusive between my OpenCL r3557 and Petri33's "x41p_zi3k, Cuda 8.00 special".

In my counter it's 4th case of same bug demonstration.

Pulse: peak=9.964181, time=45.99, period=28.63, d_freq=1544533058.61, score=1.053, chirp=26.651, fft_len=4k
Pulse: peak=9.73683, time=45.99, period=27.2, d_freq=1544533058.61, score=1.031, chirp=26.651, fft_len=4k
D: threshold 2.258369; unscaled peak power: 2.367302 exceeds threshold for 4.824%

As one can see, OpenCL reported well above threshold pulse so - not precision/rounding related case (just as before for these cases).

Place of report - the same (time/freq). But periods (and powers, but in this case powers just consequence of periods) are different.
Absolutely same case as 3 before. Wrong pulse picked up between all that found on different folding patterns in that place. I suggested place to look in very first occurence of this issue. So, 4th confirmation of bug existence here.

---

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

I think this WU is the first one I've noticed where one of my r3556 tasks got an Inconclusive against what appears to be a stable stock Windows host. The signal counts match, though, so it must be something subtle.

Workunit 2332864190 (21fe09ab.7357.18068.5.32.196)
Task 5300443647 (S=10, A=0, P=6, T=1, G=1) SSE3xj Win32 Build 3556
Task 5300443648 (S=10, A=0, P=6, T=1, G=1) v8.00 windows_intelx86

Validated by third SoG. All w/o threshold printing so manual work required to say how far from threshold pulses were, signal counters just the same in all 3. (First one with threshold printing so lets see...)

Spike: peak=24.80969, time=87.24, d_freq=1419411785.12, chirp=1.4215, fft_len=128k											Spike: peak=24.80969, time=87.24, d_freq=1419411785.12, chirp=1.4215, fft_len=128k
Spike: peak=25.3747, time=87.24, d_freq=1419411785.12, chirp=1.4224, fft_len=128k											Spike: peak=25.3747, time=87.24, d_freq=1419411785.12, chirp=1.4224, fft_len=128k
Spike: peak=24.8094, time=87.24, d_freq=1419411785.13, chirp=1.4234, fft_len=128k											Spike: peak=24.8094, time=87.24, d_freq=1419411785.13, chirp=1.4234, fft_len=128k
Spike: peak=24.04475, time=87.24, d_freq=1419415385.76, chirp=5.9282, fft_len=128k											Spike: peak=24.04474, time=87.24, d_freq=1419415385.76, chirp=5.9282, fft_len=128k
Spike: peak=25.90574, time=87.24, d_freq=1419415385.77, chirp=5.9291, fft_len=128k											Spike: peak=25.90574, time=87.24, d_freq=1419415385.77, chirp=5.9291, fft_len=128k
Spike: peak=26.56526, time=87.24, d_freq=1419415385.78, chirp=5.9301, fft_len=128k											Spike: peak=26.56526, time=87.24, d_freq=1419415385.78, chirp=5.9301, fft_len=128k
Spike: peak=25.94405, time=87.24, d_freq=1419415385.78, chirp=5.931, fft_len=128k											Spike: peak=25.94406, time=87.24, d_freq=1419415385.78, chirp=5.931, fft_len=128k
Spike: peak=24.13967, time=87.24, d_freq=1419415385.79, chirp=5.9319, fft_len=128k											Spike: peak=24.13967, time=87.24, d_freq=1419415385.79, chirp=5.9319, fft_len=128k
Pulse: peak=2.539017, time=5.99, period=0.6969, d_freq=1419416468.8, score=1.012, chirp=19.613, fft_len=256 											Pulse: peak=2.539017, time=5.99, period=0.6969, d_freq=1419416468.8, score=1.012, chirp=19.613, fft_len=256 
D:      threshold 0.0539219; unscaled peak power: 0.05440334 exceeds threshold for 0.8928%											
Pulse: peak=2.53191, time=5.99, period=0.6969, d_freq=1419416471.97, score=1.01, chirp=20.142, fft_len=256 											Pulse: peak=2.531911, time=5.99, period=0.6969, d_freq=1419416471.97, score=1.01, chirp=20.142, fft_len=256 
D:      threshold 0.0540199; unscaled peak power: 0.05439276 exceeds threshold for 0.6902%											
Spike: peak=24.02079, time=46.98, d_freq=1419409835.64, chirp=21.01, fft_len=128k											Spike: peak=24.02079, time=46.98, d_freq=1419409835.64, chirp=21.01, fft_len=128k
Spike: peak=24.58228, time=46.98, d_freq=1419409835.65, chirp=21.012, fft_len=128k											Spike: peak=24.58227, time=46.98, d_freq=1419409835.65, chirp=21.012, fft_len=128k
Triplet: peak=9.369192, time=6.016, period=4.981, d_freq=1419416738.68, chirp=-24.383, fft_len=256 											Triplet: peak=9.369189, time=6.016, period=4.981, d_freq=1419416738.68, chirp=-24.383, fft_len=256 
Gaussian: peak=3.675008, mean=0.5456764, ChiSq=1.406728, time=78.01, d_freq=1419418787.66,											Gaussian: peak=3.675009, mean=0.5456763, ChiSq=1.406729, time=78.01, d_freq=1419418787.66,
        score=0.4186165, null_hyp=2.268583, chirp=69.622, fft_len=16k											        score=0.418625, null_hyp=2.268584, chirp=69.622, fft_len=16k
Pulse: peak=6.248314, time=11.97, period=2.235, d_freq=1419416334.2, score=1.017, chirp=-71.56, fft_len=256 											Pulse: peak=6.248315, time=11.97, period=2.235, d_freq=1419416334.2, score=1.017, chirp=-71.56, fft_len=256 
D:      threshold 0.1123426; unscaled peak power: 0.1139427 exceeds threshold for 1.424%											
Pulse: peak=3.591187, time=17.94, period=1.157, d_freq=1419416042.6, score=1.008, chirp=74.21, fft_len=256 											Pulse: peak=3.591187, time=17.94, period=1.157, d_freq=1419416042.6, score=1.008, chirp=74.21, fft_len=256 
D:      threshold 0.07106485; unscaled peak power: 0.07150516 exceeds threshold for 0.6196%											
Pulse: peak=3.653561, time=17.94, period=1.157, d_freq=1419416052.02, score=1.025, chirp=76.861, fft_len=256 											Pulse: peak=3.653561, time=17.94, period=1.157, d_freq=1419416052.02, score=1.025, chirp=76.861, fft_len=256 
D:      threshold 0.06976143; unscaled peak power: 0.07114729 exceeds threshold for 1.987%											
Pulse: peak=6.321055, time=17.94, period=2.313, d_freq=1419416061.42, score=1.027, chirp=79.51, fft_len=256 											Pulse: peak=6.321057, time=17.94, period=2.313, d_freq=1419416061.42, score=1.027, chirp=79.51, fft_len=256 
D:      threshold 0.1113693; unscaled peak power: 0.113965 exceeds threshold for 2.331%											
											
Best spike: peak=26.56526, time=87.24, d_freq=1419415385.78, chirp=5.9301, fft_len=128k											Best spike: peak=26.56526, time=87.24, d_freq=1419415385.78, chirp=5.9301, fft_len=128k
Best autocorr: peak=17.27914, time=87.24, delay=3.0895, d_freq=1419411483.18, chirp=-29.565, fft_len=128k											Best autocorr: peak=17.27913, time=87.24, delay=3.0895, d_freq=1419411483.18, chirp=-29.565, fft_len=128k
Best gaussian: peak=3.675008, mean=0.5456764, ChiSq=1.406728, time=78.01, d_freq=1419418787.66,											Best gaussian: peak=3.675009, mean=0.5456763, ChiSq=1.406729, time=78.01, d_freq=1419418787.66,
        score=0.4186165, null_hyp=2.268583, chirp=69.622, fft_len=16k											        score=0.418625, null_hyp=2.268584, chirp=69.622, fft_len=16k
Best pulse: peak=6.321056, time=17.94, period=2.313, d_freq=1419416061.42, score=1.027, chirp=79.51, fft_len=256 											Best pulse: peak=6.321057, time=17.94, period=2.313, d_freq=1419416061.42, score=1.027, chirp=79.51, fft_len=256 
Best triplet: peak=9.369192, time=6.016, period=4.981, d_freq=1419416738.68, chirp=-24.383, fft_len=256 											Best triplet: peak=9.369189, time=6.016, period=4.981, d_freq=1419416738.68, chirp=-24.383, fft_len=256 

After reordering both SoG looks identical. Hard to say what CPU stock reported.

---

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

After reordering both SoG looks identical. Hard to say what CPU stock reported.

Okay, I just uploaded the Workunit file to a cloud drive, if you want to try an offline test.

Raistmer, do you or some other dev happen to need some of these workunits? I'm running rather old r3330 on ATI and SSE3xj r3330 on CPU which have proven to be very stable. I can save the workunit files and results created by my PC if needed.

blc2_2bit_guppi_57424_82409_HIP9598_OFF_0010.2706.831.18.27.9.vlar
blc2_2bit_guppi_57424_84052_HIP9727_0015.16679.831.18.27.24.vlar
blc3_2bit_guppi_57424_41210_HIP63608_0013.29546.416.18.27.238.vlar
blc3_2bit_guppi_57451_27376_HIP69732_OFF_0026.23989.831.17.26.57.vlar
blc6_2bit_guppi_57398_MESSIER031_0017.17065.0.23.46.202
blc6_2bit_guppi_57397_MESSIER031_0011.9745.0.23.46.153
02ja09ab.27298.85144.11.38.219
09ja09ab.2683.11524.15.42.26
12mr09aa.6314.22158.4.31.166
20mr09aa.28833.7843.6.33.135

Then there is this one where two ATI apps disagreed on the outcome:
30dc09aj.2161.11528.4.31.30

Edit: got two more resends while I was composing my message:
blc4_2bit_guppi_57424_39246_HIP63510_0007.28578.0.18.27.88.vlar
blc4_2bit_guppi_57424_40226_HIP63608_OFF_0010.24350.0.17.26.145.vlar

---

Unfortunately I have no time to look at every inconclusive by myself.
Most of them either from too overclocked hardware or from older apps with alerady known limitations in validation behavior.

So would be good to filter those inconclusives by "interesting" score.
For older revs that run on main - it's definitely non-overflowed result with strong enough signals (to exclude some rounding noise) paired with known-to-be-stable host.
Such results if they disagree between each other could represent some source for further bug-hunting.

---

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

I'm going to go ahead and post this one since it's now the second recent example of r3556 coming up Inconclusive against an apparently stable host running the stock Windows CPU app. Again, the signal counts appear to match so it's not clear what's causing the Inconclusive.

Workunit 2333076601 (21fe09ab.20049.19704.7.34.20)
Task 5300892747 (S=0, A=3, P=1, T=3, G=1) v8.00 windows_intelx86
Task 5300892748 (S=0, A=3, P=1, T=3, G=1) SSE3xj Win32 Build 3556

Note that the WU was split from the same tape, 21fe09ab, as the earlier example I posted a couple days ago. Don't know if that might be significant or not.