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.

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

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.

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

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.

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.

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.

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)

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!

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

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?

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.

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

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.

I think all bets are off whenever the application punts the task to the cpu because of too many triplets found. This goes for the SoG app too. If the task gets shifted from the gpu to the cpu because the bins were exceeded, the task usually will go inconclusive until two hosts process it entirely on a cpu. Discounting any flavor of Mac of course.

---

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

A proud member of the OFA (Old Farts Association)

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?

The definition of a pulse or a triplet has not changed. The special app finds valid pulses and valid triplets that are there in the WU.

The definition has been changed if it find Pulses where the CPU application finds Triplets, or it finds Triplets where the CPU application finds Pulses. It needs to produce the same result as the reference.

To begin with the data in a noise bomb is invalid.

The data isn't invalid, it is just noisy. If it were invalid then the WU would error out.
This is what happened with that GBT file a few weeks back- the data wasn't valid, so the splitters errored out.
If the splitters produce invalid WUs, then the application Errors them out when it tries to run them (as has happened in the past).

While it may be noisy, and we can't make use of it, the data is still Valid.

You can not make a valid report from invalid data.

Of course not, it's called an Error, just as I pointed out above.

30 anything means the WU has noise and it should be discarded and the computation stopped. Noise bombs have no usable data. They need not report anything. Just label the WU invalid.

Why label something that is valid, as invalid?
If 2 applications agree that the WU is a noise bomb, and they agree on the type of noise (Pulses or Triplets) then the result is Valid & Credit is granted. If not, a 3rd WU is issued & Credit will be granted to that & the WU it matches up with. A Valid result. The one that doesn't match is Invalid, is marked as such, and receives no Credit.

Noise bombs have no usable data

For the current applications, hence they stop being processed when 30 Pulses/Triplets are found. But people should get Credit for the work they do, as long as they produce a Valid result. But If their application doesn't match the reference one, then they won't get Credit as it's not a Valid result.

---

Grant
Darwin NT

Boincmgr could reschedule a noise bomb (any 30/30 task) to CPU. I think that would be waste of resources.

The definition of a pulse or a triplet has not changed. The special app finds valid pulses and valid triplets that are there in the WU.

There are just so many of them. 30 or more to choose from in a noise bomb. To begin with the data in a noise bomb is invalid. You can not make a valid report from invalid data. 30 anything means the WU has noise and it should be discarded and the computation stopped. Noise bombs have no usable data. They need not report anything. Just label the WU invalid.

Petri

---

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

Hey Petri, I seem to remember some other 'special case' where the problem was solved by dropping back to serial computing.

Maybe that needs to be done here as well, if noisy because of a triplet overflow, goto serial processing.
It shouldn't be a big deal, only a few seconds more work.

What If, What If, What If. What If a Large Asteroid comes hurtling out of the Sun and strikes in the heart of Australia?
Well, it won't be pretty, but, there is not much that can be done beforehand. I suppose we'll have to deal with it after it happens.

True, but one of those events is much more likely than the other.

---

Grant
Darwin NT