Message boards :
Number crunching :
Arecibo Overflow Tasks Run With CUDA Special App Sometimes Filled With Triplets Only
Message board moderation
Previous · 1 · 2
Author | Message |
---|---|
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
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. |
petri33 Send message Joined: 6 Jun 02 Posts: 1668 Credit: 623,086,772 RAC: 156 |
This is interesting. I found two BLC Overflows also filled with Triplets; 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 |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
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. |
rob smith Send message Joined: 7 Mar 03 Posts: 22200 Credit: 416,307,556 RAC: 380 |
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? |
petri33 Send message Joined: 6 Jun 02 Posts: 1668 Credit: 623,086,772 RAC: 156 |
This is interesting. I found two BLC Overflows also filled with Triplets; 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 |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
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! |
Keith Myers Send message Joined: 29 Apr 01 Posts: 13164 Credit: 1,160,866,277 RAC: 1,873 |
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) |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
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. |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
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. |
Brent Norman Send message Joined: 1 Dec 99 Posts: 2786 Credit: 685,657,289 RAC: 835 |
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. |
Brent Norman Send message Joined: 1 Dec 99 Posts: 2786 Credit: 685,657,289 RAC: 835 |
One that you might want to look at http://setiathome.berkeley.edu/workunit.php?wuid=3131317505 |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
This is probably relevant, RFI removal Particularly; Low chirp rate RFIThe 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. |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
So, how about this one? It's an Arecibo Overflow Filled with only Triplets, and it Validated against an ATI machine.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. 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: 0It 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 |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
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. |
©2024 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.