The point is, there have been cases where when the Apps disagreed, the CUDA App was Correct, I.E.
1) The Bad Best gaussians on the SoG Apps
2) The Entire groups of Apps from the AKv8 folder that Don't report most Pulses when the score is Exactly One.

So, it's not inconceivable that the CUDA App just May be correct on the Arecibo Overflows filled with Triplets.
They don't happen very often, and you would think with the possibilities they would happen at least once in awhile, they do happen on BLCs.
Maybe they Do happen every once in awhile on Arecibos, but only with the CUDA App.

This is interesting. I found two BLC Overflows also filled with Triplets;
http://setiathome.berkeley.edu/workunit.php?wuid=3123251218
Download http://boinc2.ssl.berkeley.edu/sah/download_fanout/35a/blc11_2bit_guppi_58227_21475_HIP66640_0059.30937.0.22.45.81.vlar
http://setiathome.berkeley.edu/workunit.php?wuid=3123251224
Download http://boinc2.ssl.berkeley.edu/sah/download_fanout/4c/blc11_2bit_guppi_58227_21475_HIP66640_0059.30937.0.22.45.84.vlar
However, on these the other Apps mostly agree. So, why don't they agree on the Arecibo files when they agree on the BLCs?

I downloaded the first one. I'll run a test. The second one was gone before I could DL it.

---

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

Yes, one of them has already validated, meaning over 50% of the signals matched.
I'm just curious as to why some would expect BLC overflows to be sometimes filled with Triplets, but Not Arecibo overflows.
Unless someone can point out why you should Never have an Arecibo Overflow filled with Triplets, I'm going to lean towards you Should find at least a few Arecibo Overflows filled with Triplets and if you don't, then there might be something wrong with the software that is not finding any Arecibo Overflows filled with Triplets.

Unless one type of signal is an artifact of the telescope I would expect to see a "fair distribution" of high triplet counts across both sources for Work Units of comparable Angular Range. One thing to think on is that the majority of GBT data has a much smaller AR than the majority of Arecibo data, and if triplets are an artifact of AR then that might (and only might) explain the difference.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

This is interesting. I found two BLC Overflows also filled with Triplets;
http://setiathome.berkeley.edu/workunit.php?wuid=3123251218
Download http://boinc2.ssl.berkeley.edu/sah/download_fanout/35a/blc11_2bit_guppi_58227_21475_HIP66640_0059.30937.0.22.45.81.vlar
http://setiathome.berkeley.edu/workunit.php?wuid=3123251224
Download http://boinc2.ssl.berkeley.edu/sah/download_fanout/4c/blc11_2bit_guppi_58227_21475_HIP66640_0059.30937.0.22.45.84.vlar
However, on these the other Apps mostly agree. So, why don't they agree on the Arecibo files when they agree on the BLCs?

I downloaded the first one. I'll run a test. The second one was gone before I could DL it.

The reference on CPU had 23 triplets and then 7 pulses. GPU reported 7 more triplets and stopped at 30/30 before reporting those 7 pulses.

On a noise bomb you can find all kinds of spikes, pulses and triplets. Triplets get more common when more high spikes are found because the odds that three spikes are evenly spaced increases. And the longer the sample the more there is those noise induced spikes. No alien signal, just cell phone, radar, satellite, ... electromagnetic noise from Tellus and some wasted seconds of processing time.

---

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

The important part is, Both BLC Overflows filled with Triplets Validated.
If these would have been Two Arecibo Overflows filled with Triplets Both would have been Invalid.
For some reason the Only App reporting Arecibo Overflows filled with Triplets is the CUDA App, Why?
There Should be at least Some Arecibo Overflows filled with Triplets, Why aren't the Other Apps reporting any?

Listing executable(s) in /APPS :
setiathome_x41p_V0.97b2_x86_64-apple-darwin_cuda91

Listing executable in /REF_APPs :
MBv8_8.22r3711_sse41_x86_64-apple-darwin
---------------------------------------------------
Current WU: blc11_2bit_guppi_58227_21475_HIP66640_0059.30937.0.22.45.81.vlar.wu
---------------------------------------------------
Running default app with command : MBv8_8.22r3711_sse41_x86_64-apple-darwin
       27.44 real        25.31 user         0.11 sys
Elapsed Time: ………………………………… 28 seconds
---------------------------------------------------
Running app with command : setiathome_x41p_V0.97b2_x86_64-apple-darwin_cuda91 -nobs -device 1
        5.44 real         2.32 user         1.05 sys
Elapsed Time : ……………………………… 6 seconds
Speed compared to default : 466 %
-----------------
Comparing results
                ------------- R1:R2 ------------     ------------- R2:R1 ------------
                Exact  Super  Tight  Good    Bad     Exact  Super  Tight  Good    Bad
        Spike      0      0      0      0      0        0      0      0      0      0
     Gaussian      0      0      0      0      0        0      0      0      0      0
        Pulse      0      0      0      0      7        0      0      0      0      0
      Triplet      0     23     23     23      0        0     23     23     23      7
   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     23     23     23      7        0     23     23     23      7

Unmatched signal(s) in R1 at line(s) 595 625 673 695 717 765 855
Unmatched signal(s) in R2 at line(s) 731 748 765 782 799 816 833
For R1:R2 matched signals only, Q= 99.97%
Result      : Weakly similar.
---------------------------------------------------
Done with blc11_2bit_guppi_58227_21475_HIP66640_0059.30937.0.22.45.81.vlar.wu.
Current WU: blc11_2bit_guppi_58227_21475_HIP66640_0059.30937.0.22.45.84.vlar.wu
---------------------------------------------------
Running default app with command : MBv8_8.22r3711_sse41_x86_64-apple-darwin
      249.78 real       246.36 user         0.59 sys
Elapsed Time: ………………………………… 250 seconds
---------------------------------------------------
Running app with command : setiathome_x41p_V0.97b2_x86_64-apple-darwin_cuda91 -nobs -device 1
        6.96 real         3.56 user         1.25 sys
Elapsed Time : ……………………………… 7 seconds
Speed compared to default : 3571 %
-----------------
Comparing results
                ------------- R1:R2 ------------     ------------- R2:R1 ------------
                Exact  Super  Tight  Good    Bad     Exact  Super  Tight  Good    Bad
        Spike      0      0      0      0      0        0      0      0      0      0
     Gaussian      0      0      0      0      0        0      0      0      0      0
        Pulse      0      0      0      0      1        0      0      0      0      0
      Triplet      1     29     29     29      0        1     29     29     30      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
                ----   ----   ----   ----   ----     ----   ----   ----   ----   ----
                   1     29     29     29      1        1     29     29     30      0

Unmatched signal(s) in R1 at line(s) 833
For R1:R2 matched signals only, Q= 99.95%
Result      : Weakly similar.
---------------------------------------------------
Done with blc11_2bit_guppi_58227_21475_HIP66640_0059.30937.0.22.45.84.vlar.wu.

Done with Benchmark run! Removing temporary files!

I could swear I've seen an occasional, rare, Arecibo Overflow task filled with Triplets. I'll have to put a Post-It on the monitor to keep a watchful eye out for those when I look at my tasks.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

One of possible ways to fix this issue is to store more signals of each type than limit says separately.
And do CPU-based reordering and selection from these signal pools on final report.
This would allow fully parallell processing on GPU side still improving validation rate.
That's how OpenCL SoG operates currently. Of course same issue there too - on overflow too many signals exist to be reported as whole so some selection required.

---

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

For some reason the Only App reporting Arecibo Overflows filled with Triplets is the CUDA App, Why?
There Should be at least Some Arecibo Overflows filled with Triplets, Why aren't the Other Apps reporting any?
[/pre]

Such statement could imply that reported triplets are invalid ones, not just another subset of all task signals.
What I would propose to check this possibility is to change thresholds and limits in task under question.
This would allow:
1) increasing pulse threshold will effectively remove pulse signals from output so if CPU (for example) app overflows on Pulses while CUDA - on Tripet such modification would allow CPU app to continue search and maybe to find those Triplets too.
2) increasing limits for reporting signals (better to test with CPU apps cause GPU apps could be hardwired to particular number due to GPU memory restrictions and peculierities of design) will allow CPU apps to prolong processign and report both subsets of signals original CPU and GPU runs did. But if there are no same Triplets in whole output of modded task and CPU app as were in original task and GPU app - then severity of issue increases indeed - that would mean not just another subset of valid signals but invalid signals instead.
So the check is possible, just testing task modification required.

---

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

Just a comment,
I been thinking about 'Noise is noise, it's garbage' line of thought and IF they even track overflowed tasks and/or their results. So why does it matter if they just toss everything with a resut_overflow as had been said.

Then I think, about overclocking, heat issues, etc. that also produce this type of a result ... so yes it does matter that the applications agree with each other in a specific way and not just categorize it as 'noise'.

Just my 2 cents worth.

One that you might want to look at
http://setiathome.berkeley.edu/workunit.php?wuid=3131317505

This is probably relevant, RFI removal
Particularly;

Low chirp rate RFI
Terrestrial RFI isn't chirped, because the sender's reference frame is the same as the receiver. Celestial signals are very unlikely to have near-zero chirp rate. So we remove signals with longer FFT lengths (i.e. precise frequency measurement) and very low chirp rates.

The Chirp rate on that Noise Bomb was from 0 to 0.0018485, so, it will be removed.
Not to mention you seem to be concerned about One signal that was reported out of possibly thousands that went Unreported.
What about all those signals that were Unreported?

When peoples misbehaving machines return Overflows, the Wingmen usually don't. Which is usually how you can spot a misbehaving machines returning overflows, if both return Overflows both will most likely be removed as RFI.

For some reason the Only App reporting Arecibo Overflows filled with Triplets is the CUDA App, Why?There Should be at least Some Arecibo Overflows filled with Triplets, Why aren't the Other Apps reporting any?

Such statement could imply that reported triplets are invalid ones, not just another subset of all task signals.
What I would propose to check this possibility is to change thresholds and limits in task under question.
This would allow:
1) increasing pulse threshold will effectively remove pulse signals from output so if CPU (for example) app overflows on Pulses while CUDA - on Tripet such modification would allow CPU app to continue search and maybe to find those Triplets too.
2) increasing limits for reporting signals (better to test with CPU apps cause GPU apps could be hardwired to particular number due to GPU memory restrictions and peculierities of design) will allow CPU apps to prolong processign and report both subsets of signals original CPU and GPU runs did. But if there are no same Triplets in whole output of modded task and CPU app as were in original task and GPU app - then severity of issue increases indeed - that would mean not just another subset of valid signals but invalid signals instead.
So the check is possible, just testing task modification required.

So, how about this one? It's an Arecibo Overflow Filled with only Triplets, and it Validated against an ATI machine.
https://setiathome.berkeley.edu/workunit.php?wuid=3132578153

WU true angle range is :  0.432538
Sigma 3
Thread call stack limit is: 1k
Triplet: peak=11.72904, time=18.59, period=0.06554, d_freq=1420015563.96, chirp=0, fft_len=128 
Triplet: peak=12.43143, time=18.59, period=0.06554, d_freq=1420015554.44, chirp=-0.51204, fft_len=128 
Triplet: peak=13.76983, time=18.59, period=0.06554, d_freq=1420015544.94, chirp=-1.0232, fft_len=128 
Triplet: peak=14.26597, time=18.59, period=0.06554, d_freq=1420015535.42, chirp=-1.5352, fft_len=128 
Triplet: peak=14.00156, time=18.59, period=0.06554, d_freq=1420015535.24, chirp=2.5584, fft_len=128 
Triplet: peak=13.51071, time=18.59, period=0.06554, d_freq=1420015544.76, chirp=3.0704, fft_len=128 
Triplet: peak=12.2505, time=18.59, period=0.06554, d_freq=1420015554.28, chirp=3.5824, fft_len=128 
Triplet: peak=11.57855, time=18.59, period=0.06554, d_freq=1420015563.78, chirp=4.0936, fft_len=128 
Triplet: peak=11.99259, time=18.59, period=0.06554, d_freq=1420015564.15, chirp=-4.0936, fft_len=128 
Triplet: peak=12.62753, time=18.59, period=0.06554, d_freq=1420015554.63, chirp=-4.6056, fft_len=128 
Triplet: peak=13.93171, time=18.59, period=0.06554, d_freq=1420015545.11, chirp=-5.1176, fft_len=128 
Triplet: peak=14.34208, time=18.59, period=0.06554, d_freq=1420015535.61, chirp=-5.6287, fft_len=128 
Triplet: peak=13.88231, time=18.59, period=0.06554, d_freq=1420015535.07, chirp=6.6528, fft_len=128 
Triplet: peak=13.53132, time=18.59, period=0.06554, d_freq=1420015544.57, chirp=7.1639, fft_len=128 
Triplet: peak=12.39481, time=18.59, period=0.06554, d_freq=1420015554.09, chirp=7.676, fft_len=128 
Triplet: peak=11.71143, time=18.59, period=0.06554, d_freq=1420015563.6, chirp=8.1871, fft_len=128 
Triplet: peak=12.21237, time=18.59, period=0.06554, d_freq=1420015564.33, chirp=-8.1871, fft_len=128 
Triplet: peak=12.60988, time=18.59, period=0.06554, d_freq=1420015554.81, chirp=-8.6991, fft_len=128 
Triplet: peak=13.76129, time=18.59, period=0.06554, d_freq=1420015545.29, chirp=-9.2112, fft_len=128 
Triplet: peak=14.07038, time=18.59, period=0.06554, d_freq=1420015535.79, chirp=-9.7223, fft_len=128 
Triplet: peak=13.99327, time=18.59, period=0.06554, d_freq=1420015534.89, chirp=10.746, fft_len=128 
Triplet: peak=13.86119, time=18.59, period=0.06554, d_freq=1420015544.39, chirp=11.257, fft_len=128 
Triplet: peak=12.84603, time=18.59, period=0.06554, d_freq=1420015553.91, chirp=11.77, fft_len=128 
Triplet: peak=12.09439, time=18.59, period=0.06554, d_freq=1420015563.43, chirp=12.282, fft_len=128 
Triplet: peak=12.28945, time=18.59, period=0.06554, d_freq=1420015564.5, chirp=-12.282, fft_len=128 
Triplet: peak=11.63333, time=18.59, period=0.06554, d_freq=1420015572.93, chirp=12.793, fft_len=128 
Triplet: peak=12.4142, time=18.59, period=0.06554, d_freq=1420015555, chirp=-12.793, fft_len=128 
Triplet: peak=13.42208, time=18.59, period=0.06554, d_freq=1420015545.48, chirp=-13.305, fft_len=128 
Triplet: peak=13.67142, time=18.59, period=0.06554, d_freq=1420015535.96, chirp=-13.817, fft_len=128 
Triplet: peak=14.16545, time=18.59, period=0.06554, d_freq=1420015534.7, chirp=14.84, fft_len=128 
SETI@Home Informational message -9 result_overflow
NOTE: The number of results detected equals the storage space allocated.

Best spike: peak=23.89134, time=46.98, d_freq=1420014942.64, chirp=-14.283, fft_len=128k
Best autocorr: peak=16.38738, time=60.4, delay=2.3978, d_freq=1420018867.4, chirp=-10.991, fft_len=128k
Best gaussian: peak=3.291257, mean=0.5551064, ChiSq=1.351635, time=15.94, d_freq=1420014835.21,
	score=-2.15582, null_hyp=2.09566, chirp=-5.2969, fft_len=16k
Best pulse: peak=3.987181, time=12.45, period=1.293, d_freq=1420017716.46, score=0.9698, chirp=13.561, fft_len=512 
Best triplet: peak=14.34208, time=18.59, period=0.06554, d_freq=1420015535.61, chirp=-5.6287, fft_len=128 

Spike count:    0
Autocorr count: 0
Pulse count:    0
Triplet count:  30
Gaussian count: 0

It did run for a little longer than most, Run time: 1 min 16 sec, however, if it's possible to run that long and record only Triplets, then a shorter run-time with only Triplets must be possible...with Valid signals.


Hmmm, here's another Arecibo mostly filled with Triplets,
Spike count: 0
Autocorr count: 0
Pulse count: 5
Triplet count: 25
Gaussian count: 0
Interestingly, it was also validated by an ATI. So, it would would appear the CUDA App is quite capable of producing Valid Overflows Filled with Triplets. So, Why do so many of them end up Invalid?

Here's another one, let's see what happens to this one. From what we've seen, it's most likely Valid,
https://setiathome.berkeley.edu/result.php?resultid=6931717349

If you want me to do offline task modifications please save task on some storage, to retrieve it later.

---

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