Monitoring inconclusive GBT validations and harvesting data for testing

Message boards : Number crunching : Monitoring inconclusive GBT validations and harvesting data for testing
Message board moderation

To post messages, you must log in.

Previous · 1 . . . 18 · 19 · 20 · 21 · 22 · 23 · 24 . . . 36 · Next

AuthorMessage
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1820954 - Posted: 30 Sep 2016, 22:24:45 UTC - in response to Message 1820949.  
Last modified: 30 Sep 2016, 22:48:52 UTC

Overflow results may not be useless.

I would support such point of view.
Though most of them most probably RFI some could be just new WoW ones.
So, we need to mark them differently and definitely not as "bad task".
If we speaking about any server-side changes here I would try to keep them minimal like proposed here:
http://setiweb.ssl.berkeley.edu/beta/forum_thread.php?id=2266&postid=59660
http://setiweb.ssl.berkeley.edu/beta/forum_thread.php?id=2266&postid=59665
This would keep some of signals inside database, allows to mark task as "overflowed" for special treatment on further post-processing stages and reduces the need of re-processing on distributed stage.
SETI apps news
We're not gonna fight them. We're gonna transcend them.
ID: 1820954 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1820957 - Posted: 30 Sep 2016, 22:52:03 UTC - in response to Message 1820954.  
Last modified: 30 Sep 2016, 22:59:37 UTC

Overflow results may not be useless.

I would support such point of view.
Though most of them most probably RFI some could be just new WoW ones.
So, we need to mark them differently and definitely not as "bad task".
If we speaking about any server-side changes here I would try to keep them minimal like proposed here: http://setiweb.ssl.berkeley.edu/beta/forum_thread.php?id=2266&postid=59665
This would keep some of signals inside database, allows to mark task as "overflowed" for special treatment on further post-processing stages and reduces the need of re-processing on distributed stage.



Well hypothetical (tin-foil hat) Scenario: Parkes and/or FAST or other telescope data becomes available processing, 95 % of these are late overflows for undetermined reasons yet (Hillary Clinton gained presidency, and secretly is paid off by anti-science nutjobs to have the military beam radar at the dishes).

Under old scenario, the overflows allow isolation of the offending signals, and countermeasures to be devised (e.g. filtering specific patterned data methodically before sending it out for processing)

Altered postprocessing scenario, same bandwidth to send the tasks out has been spent, but now another step needs to be done to obtain useful data on 95% of the data already processed [to reduce it by creating countermeasures].

Would sound pretty far fetched if that wasn't already pretty much what happens with Arecibo data (RFI rejection of some entire tapes).
"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.
ID: 1820957 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1821036 - Posted: 1 Oct 2016, 5:29:50 UTC - in response to Message 1820957.  


Well hypothetical (tin-foil hat) Scenario: Parkes and/or FAST or other telescope data becomes available processing, 95 % of these are late overflows for undetermined reasons yet

Such case needs to be solved before release to main apparently.
SETI apps news
We're not gonna fight them. We're gonna transcend them.
ID: 1821036 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1821040 - Posted: 1 Oct 2016, 5:52:43 UTC - in response to Message 1821036.  


Well hypothetical (tin-foil hat) Scenario: Parkes and/or FAST or other telescope data becomes available processing, 95 % of these are late overflows for undetermined reasons yet

Such case needs to be solved before release to main apparently.


yep!
"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.
ID: 1821040 · Report as offensive
Profile petri33
Volunteer tester

Send message
Joined: 6 Jun 02
Posts: 1668
Credit: 623,086,772
RAC: 156
Finland
Message 1821061 - Posted: 1 Oct 2016, 9:27:51 UTC
Last modified: 1 Oct 2016, 9:29:07 UTC

A packet is is sent to two computers initially. A superhighly optimized app could read the first computers results (from stderr or db) and just verify that those signals really exist. It would take 3-10 seconds per packet.

I know that this would be considered unethical by some especially if done to 'valid' packets having less than 30 signals. But this could be done to 30/30 packets be early or late. Just to confirm that those reported 30 or more signals are scientifically 'good'.

I'll not implement that but given time enough someone will.
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
ID: 1821061 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1821062 - Posted: 1 Oct 2016, 9:33:20 UTC - in response to Message 1821061.  

A packet is is sent to two computers initially. A superhighly optimized app could read the first computers results (from stderr or db) and just verify that those signals really exist. It would take 3-10 seconds per packet.

I know that this would be considered unethical by some especially if done to 'valid' packets having less than 30 signals. But this could be done to 30/30 packets be early or late. Just to confirm that those reported 30 or more signals are scientifically 'good'.

I'll not implement that but given time enough someone will.


Yeah, p2p does open some doors for collusion. If that reached a point of concern across the totality of Boinc Projects (while there are easier exploits), then they would likely start signing/encrypting tasks pretty quickly (compression means are already there)
"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.
ID: 1821062 · Report as offensive
Mark Stevenson Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 8 Sep 11
Posts: 1736
Credit: 174,899,165
RAC: 91
United Kingdom
Message 1821063 - Posted: 1 Oct 2016, 9:52:11 UTC - in response to Message 1821062.  
Last modified: 1 Oct 2016, 9:52:42 UTC

Yeah, p2p does open some doors for collusion. If that reached a point of concern across the totality of Boinc Projects (while there are easier exploits), then they would likely start signing/encrypting tasks pretty quickly (compression means are already there)


maybe very nieve here but people would do that just for credits , messing up the "science d/b" as they do it . Those sad people need castrating / neutering .
Life is what you make of it :-)

When i'm good i'm very good , but when i'm bad i'm shi#eloads better ;-) In't I " buttercups " p.m.s.l at authoritie !!;-)
ID: 1821063 · Report as offensive
Profile jason_gee
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 24 Nov 06
Posts: 7489
Credit: 91,093,184
RAC: 0
Australia
Message 1821065 - Posted: 1 Oct 2016, 10:02:04 UTC - in response to Message 1821063.  

Yeah, p2p does open some doors for collusion. If that reached a point of concern across the totality of Boinc Projects (while there are easier exploits), then they would likely start signing/encrypting tasks pretty quickly (compression means are already there)


maybe very nieve here but people would do that just for credits , messing up the "science d/b" as they do it . Those sad people need castrating / neutering .


They would try, but my feeling is people with the actual skills to do so have better things to do (Pretty sure at least Petri, Raistmer and myself do). It'd be a good way for getting applications fingerprinted and banned. Killing off Anonymous platform altogether would hurt project development a lot, defeating the purpose of having it open source, but if the science was compromised by activities well they'd have to close it off. There are pretty low cost ways to detect exploits, when you control the result database.
"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.
ID: 1821065 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1821103 - Posted: 1 Oct 2016, 15:06:50 UTC - in response to Message 1821061.  

A packet is is sent to two computers initially. A superhighly optimized app could read the first computers results (from stderr or db) and just verify that those signals really exist. It would take 3-10 seconds per packet.

It's just incorrect way of doing validation cause it will miss false negatives.
If first host mutes some of signals such validity check will not find them.
The idea of independent re-processing is to catch both false positives and false negatives too.
SETI apps news
We're not gonna fight them. We're gonna transcend them.
ID: 1821103 · Report as offensive
Profile -= Vyper =-
Volunteer tester
Avatar

Send message
Joined: 5 Sep 99
Posts: 1652
Credit: 1,065,191,981
RAC: 2,537
Sweden
Message 1821861 - Posted: 5 Oct 2016, 6:10:00 UTC
Last modified: 5 Oct 2016, 6:12:25 UTC

I Found one!!!

http://setiathome.berkeley.edu/workunit.php?wuid=2279637413

SOG VERSION


Work Unit Info:
...............
Credit multiplier is : 2.85
WU true angle range is : 0.006367
Used GPU device parameters are:
Number of compute units: 12
Single buffer allocation size: 128MB
Total device global memory: 3072MB
max WG size: 1024
local mem type: Real
FERMI path used: yes
LotOfMem path: yes
LowPerformanceGPU path: no
period_iterations_num=50
Spike: peak=24.61833, time=5.727, d_freq=1352321279.39, chirp=-5.9643, fft_len=128k
Spike: peak=26.11531, time=5.727, d_freq=1352321279.39, chirp=-5.9656, fft_len=128k
Spike: peak=26.40693, time=5.727, d_freq=1352321279.38, chirp=-5.9669, fft_len=128k
Spike: peak=25.41258, time=5.727, d_freq=1352321279.37, chirp=-5.9681, fft_len=128k
Spike: peak=24.49572, time=5.727, d_freq=1352321279.39, chirp=-5.9796, fft_len=128k
Spike: peak=25.01148, time=5.727, d_freq=1352321279.39, chirp=-5.9808, fft_len=128k
Spike: peak=24.24306, time=5.727, d_freq=1352321279.38, chirp=-5.9821, fft_len=128k
Pulse: peak=5.914622, time=45.86, period=13.15, d_freq=1352325185.62, score=1.061, chirp=-8.9471, fft_len=1024
Pulse: peak=2.288692, time=45.84, period=3.867, d_freq=1352320459.77, score=1.002, chirp=-9.1617, fft_len=512
Pulse: peak=3.762496, time=45.86, period=9.015, d_freq=1352323815.94, score=1.004, chirp=-13.957, fft_len=1024
Spike: peak=24.19372, time=85.9, d_freq=1352327150.67, chirp=23.385, fft_len=128k
Spike: peak=24.54026, time=85.9, d_freq=1352327150.67, chirp=23.39, fft_len=128k
Pulse: peak=9.39383, time=46.17, period=28.63, d_freq=1352321706.07, score=1.02, chirp=38.231, fft_len=8k
Pulse: peak=3.339135, time=45.84, period=7.494, d_freq=1352328860.23, score=1, chirp=-40.942, fft_len=512
Pulse: peak=5.770851, time=45.86, period=13.69, d_freq=1352323539.85, score=1.034, chirp=46.311, fft_len=1024
Pulse: peak=1.297242, time=45.82, period=1.746, d_freq=1352326113.32, score=1.011, chirp=-60.411, fft_len=256
Pulse: peak=2.637339, time=45.9, period=4.593, d_freq=1352324522.16, score=1.029, chirp=74.726, fft_len=2k

Best spike: peak=26.40693, time=5.727, d_freq=1352321279.38, chirp=-5.9669, fft_len=128k
Best autocorr: peak=17.29338, time=28.63, delay=4.1283, d_freq=1352324638.74, chirp=-27.965, fft_len=128k
Best gaussian: peak=0, mean=0, ChiSq=0, time=-2.123e+011, d_freq=0,
score=-12, null_hyp=0, chirp=0, fft_len=0
Best pulse: peak=5.914622, time=45.86, period=13.15, d_freq=1352325185.62, score=1.061, chirp=-8.9471, fft_len=1024
Best triplet: peak=0, time=-2.123e+011, period=0, d_freq=0, chirp=0, fft_len=0


Flopcounter: 3909489318052.926800

Spike count: 9
Autocorr count: 0
Pulse count: 8
Triplet count: 0
Gaussian count: 0
Wallclock time elapsed since last restart: 1148.8 seconds

class Gaussian_transfer_not_needed: total=0, N=0, <>=0, min=0 max=0
class Gaussian_transfer_needed: total=0, N=0, <>=0, min=0 max=0


class Gaussian_skip1_no_peak: total=0, N=0, <>=0, min=0 max=0
class Gaussian_skip2_bad_group_peak: total=0, N=0, <>=0, min=0 max=0
class Gaussian_skip3_too_weak_peak: total=0, N=0, <>=0, min=0 max=0
class Gaussian_skip4_too_big_ChiSq: total=0, N=0, <>=0, min=0 max=0
class Gaussian_skip6_low_power: total=0, N=0, <>=0, min=0 max=0


class Gaussian_new_best: total=0, N=0, <>=0, min=0 max=0
class Gaussian_report: total=0, N=0, <>=0, min=0 max=0
class Gaussian_miss: total=0, N=0, <>=0, min=0 max=0


class PC_triplet_find_hit: total=54180, N=54180, <>=1, min=1 max=1
class PC_triplet_find_miss: total=2816, N=2816, <>=1, min=1 max=1


class PC_pulse_find_hit: total=44603, N=44603, <>=1, min=1 max=1
class PC_pulse_find_miss: total=18, N=18, <>=1, min=1 max=1
class PC_pulse_find_early_miss: total=16, N=16, <>=1, min=1 max=1
class PC_pulse_find_2CPU: total=0, N=0, <>=0, min=0 max=0


class PoT_transfer_not_needed: total=54165, N=54165, <>=1, min=1 max=1
class PoT_transfer_needed: total=2832, N=2832, <>=1, min=1 max=1

GPU device sync requested... ...GPU device synched
12:51:55 (160): called boinc_finish(0)

</stderr_txt>

PETRI VERSION
Work Unit Info:
...............
WU true angle range is : 0.006367
Sigma 710
Sigma > GaussTOffsetStop: 710 > -646
Thread call stack limit is: 1k
Spike: peak=24.61833, time=5.727, d_freq=1352321279.39, chirp=-5.9643, fft_len=128k
Spike: peak=26.11531, time=5.727, d_freq=1352321279.39, chirp=-5.9656, fft_len=128k
Spike: peak=26.40693, time=5.727, d_freq=1352321279.38, chirp=-5.9669, fft_len=128k
Spike: peak=25.41257, time=5.727, d_freq=1352321279.37, chirp=-5.9681, fft_len=128k
Spike: peak=24.49572, time=5.727, d_freq=1352321279.39, chirp=-5.9796, fft_len=128k
Spike: peak=25.01146, time=5.727, d_freq=1352321279.39, chirp=-5.9808, fft_len=128k
Spike: peak=24.24305, time=5.727, d_freq=1352321279.38, chirp=-5.9821, fft_len=128k
Pulse: peak=5.914618, time=45.86, period=13.15, d_freq=1352325185.62, score=1.061, chirp=-8.9471, fft_len=1024
Pulse: peak=2.288692, time=45.84, period=3.867, d_freq=1352320459.77, score=1.002, chirp=-9.1617, fft_len=512
Pulse: peak=3.762486, time=45.86, period=9.015, d_freq=1352323815.94, score=1.004, chirp=-13.957, fft_len=1024
Spike: peak=24.19372, time=85.9, d_freq=1352327150.67, chirp=23.385, fft_len=128k
Spike: peak=24.54028, time=85.9, d_freq=1352327150.67, chirp=23.39, fft_len=128k
Pulse: peak=9.393847, time=46.17, period=28.63, d_freq=1352321706.07, score=1.02, chirp=38.231, fft_len=8k
Pulse: peak=3.33913, time=45.84, period=7.494, d_freq=1352328860.23, score=1, chirp=-40.942, fft_len=512
setiathome_CUDA: Found 1 CUDA device(s):
Device 1: GeForce GTX 1080, 8112 MiB, regsPerBlock 65536
computeCap 6.1, multiProcs 20
pciBusID = 1, pciSlotID = 0
In cudaAcc_initializeDevice(): Boinc passed DevPref 1
setiathome_CUDA: CUDA Device 1 specified, checking...
Device 1: GeForce GTX 1080 is okay
SETI@home using CUDA accelerated device GeForce GTX 1080
Using pfb = 8 from command line args
Using pfp = 128 from command line args
Using unroll = 20 from command line args
Restarted at 30.47 percent, with setiathome enhanced x41p_zi3j, Cuda 8.00 special
Detected setiathome_enhanced_v7 task. Autocorrelations enabled, size 128k elements.
Sigma 710
Sigma > GaussTOffsetStop: 710 > -646
Thread call stack limit is: 1k
Find triplets Cuda kernel encountered too many triplets, or bins above threshold, reprocessing this PoT on CPU... err = 1
setiathome_CUDA: Found 1 CUDA device(s):
Device 1: GeForce GTX 1080, 8112 MiB, regsPerBlock 65536
computeCap 6.1, multiProcs 20
pciBusID = 1, pciSlotID = 0
In cudaAcc_initializeDevice(): Boinc passed DevPref 1
setiathome_CUDA: CUDA Device 1 specified, checking...
Device 1: GeForce GTX 1080 is okay
SETI@home using CUDA accelerated device GeForce GTX 1080
Using pfb = 8 from command line args
Using pfp = 128 from command line args
Using unroll = 20 from command line args
Restarted at 30.47 percent, with setiathome enhanced x41p_zi3j, Cuda 8.00 special
Detected setiathome_enhanced_v7 task. Autocorrelations enabled, size 128k elements.
Sigma 710
Sigma > GaussTOffsetStop: 710 > -646
Thread call stack limit is: 1k
Find triplets Cuda kernel encountered too many triplets, or bins above threshold, reprocessing this PoT on CPU... err = 1
setiathome_CUDA: Found 1 CUDA device(s):
Device 1: GeForce GTX 1080, 8112 MiB, regsPerBlock 65536
computeCap 6.1, multiProcs 20
pciBusID = 1, pciSlotID = 0
In cudaAcc_initializeDevice(): Boinc passed DevPref 1
setiathome_CUDA: CUDA Device 1 specified, checking...
Device 1: GeForce GTX 1080 is okay
SETI@home using CUDA accelerated device GeForce GTX 1080
Using pfb = 8 from command line args
Using pfp = 128 from command line args
Using unroll = 20 from command line args
Restarted at 30.47 percent, with setiathome enhanced x41p_zi3j, Cuda 8.00 special
Detected setiathome_enhanced_v7 task. Autocorrelations enabled, size 128k elements.
Sigma 710
Sigma > GaussTOffsetStop: 710 > -646
Thread call stack limit is: 1k
Spike: peak=97.2344, time=23.59, d_freq=1352327061.65, chirp=-29.776, fft_len=256
Spike: peak=134.1317, time=23.81, d_freq=1352324641.01, chirp=-29.776, fft_len=256
Spike: peak=240.1877, time=24.37, d_freq=1352324579.65, chirp=-29.776, fft_len=256
Spike: peak=240.1717, time=24.39, d_freq=1352324400.17, chirp=-29.776, fft_len=256
Spike: peak=256, time=24.42, d_freq=1352323684.25, chirp=-29.776, fft_len=256
Spike: peak=256, time=24.55, d_freq=1352324350.8, chirp=-29.776, fft_len=256
Spike: peak=51.20004, time=24.57, d_freq=1352325244.21, chirp=-29.776, fft_len=256
Spike: peak=240.16, time=24.6, d_freq=1352323678.92, chirp=-29.776, fft_len=256
Spike: peak=240.1455, time=24.62, d_freq=1352324572.32, chirp=-29.776, fft_len=256
Spike: peak=25.60004, time=24.68, d_freq=1352326045.54, chirp=-29.776, fft_len=256
Spike: peak=36.57143, time=24.71, d_freq=1352324614.36, chirp=-29.776, fft_len=256
Spike: peak=85.77132, time=24.8, d_freq=1352321840.08, chirp=-29.776, fft_len=256
Spike: peak=32.00062, time=24.95, d_freq=1352322729.49, chirp=-29.776, fft_len=256
Spike: peak=51.19973, time=24.98, d_freq=1352326305.1, chirp=-29.776, fft_len=256
Spike: peak=256, time=25.11, d_freq=1352324736.48, chirp=-29.776, fft_len=256
Spike: peak=256, time=25.15, d_freq=1352324958.67, chirp=-29.776, fft_len=256
Spike: peak=256, time=25.4, d_freq=1352324861.94, chirp=-29.776, fft_len=256
Spike: peak=256, time=25.69, d_freq=1352324138.02, chirp=-29.776, fft_len=256
SETI@Home Informational message -9 result_overflow
NOTE: The number of results detected equals the storage space allocated.

Best spike: peak=256, time=24.42, d_freq=1352323684.25, chirp=-29.776, fft_len=256
Best autocorr: peak=17.2934, time=28.63, delay=4.1283, d_freq=1352324638.74, chirp=-27.965, fft_len=128k
Best gaussian: peak=0, mean=0, ChiSq=0, time=-2.123e+11, d_freq=0,
score=-12, null_hyp=0, chirp=0, fft_len=0
Best pulse: peak=5.914618, time=45.86, period=13.15, d_freq=1352325185.62, score=1.061, chirp=-8.9471, fft_len=1024
Best triplet: peak=0, time=-2.123e+11, period=0, d_freq=0, chirp=0, fft_len=0

Flopcounter: 18627826515589.917969

Spike count: 27
Autocorr count: 0
Pulse count: 3
Triplet count: 0
Gaussian count: 0
00:12:49 (3124): called boinc_finish(0)

</stderr_txt>
]]>

AND DARWIN VERSION WUT? IT WORX :)

<core_client_version>7.6.22</core_client_version>
<![CDATA[
<stderr_txt>
OpenCL platform detected: Apple
Number of OpenCL devices found : 1
BOINC assigns slot on device #0.
Info: BOINC provided OpenCL device ID used

Build features: SETI8 Non-graphics OpenCL USE_OPENCL_HD5xxx OCL_CHIRP3 ASYNC_SPIKE FFTW SSE3 64bit
System: Darwin x86_64 Kernel: 15.6.0
CPU : Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz
GenuineIntel x86, Family 6 Model 60 Stepping 3
Features : FPU TSC PAE APIC MTRR MMX SSE SSE2 HT SSE3 SSSE3 SSE4.1 SSE4.2 AVX1.0

OpenCL-kernels filename : MultiBeam_Kernels_r3321.cl
ar=0.006367 NumCfft=116085 NumGauss=0 NumPulse=46762762368 NumTriplet=59733895584
Currently allocated 185 MB for GPU buffers
In v_BaseLineSmooth: NumDataPoints=1048576, BoxCarLength=8192, NumPointsInChunk=32768
OS X optimized setiathome_v8 application
Version info: SSE3x (Intel, Core 2-optimized v8-nographics) V5.13 by Alex Kan
SSE3x OS X 64bit Build 3321 , Ported by : Raistmer, JDWhale, Urs Echternacht


OpenCL version by Raistmer, r3321

AMD HD5 version by Raistmer

Number of OpenCL platforms: 1


OpenCL Platform Name: Apple
Number of devices: 1
Max compute units: 16
Max work group size: 256
Max clock frequency: 975Mhz
Max memory allocation: 536870912
Cache type: None
Cache line size: 0
Cache size: 0
Global memory size: 2147483648
Constant buffer size: 65536
Max number of constant args: 8
Local memory type: Scratchpad
Local memory size: 32768
Queue properties:
Out-of-Order: No
Name: AMD Radeon R9 M290 Compute Engine
Vendor: AMD
Driver version: 1.2 (Aug 29 2016 22:17:00)
Version: OpenCL 1.2
Extensions: cl_APPLE_SetMemObjectDestructor cl_APPLE_ContextLoggingFunctions cl_APPLE_clut cl_APPLE_query_kernel_names cl_APPLE_gl_sharing cl_khr_gl_event cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_image2d_from_buffer cl_khr_depth_images cl_APPLE_command_queue_priority cl_APPLE_command_queue_select_compute_units cl_khr_fp64


Work Unit Info:
...............
Credit multiplier is : 2.85
WU true angle range is : 0.006367
Used GPU device parameters are:
Number of compute units: 16
Single buffer allocation size: 128MB
Total device global memory: 2048MB
max WG size: 256
local mem type: Real
LotOfMem path: no
period_iterations_num=50
Spike: peak=24.61832, time=5.727, d_freq=1352321279.39, chirp=-5.9643, fft_len=128k
Spike: peak=26.11531, time=5.727, d_freq=1352321279.39, chirp=-5.9656, fft_len=128k
Spike: peak=26.40693, time=5.727, d_freq=1352321279.38, chirp=-5.9669, fft_len=128k
Spike: peak=25.41257, time=5.727, d_freq=1352321279.37, chirp=-5.9681, fft_len=128k
Spike: peak=24.49572, time=5.727, d_freq=1352321279.39, chirp=-5.9796, fft_len=128k
Spike: peak=25.01146, time=5.727, d_freq=1352321279.39, chirp=-5.9808, fft_len=128k
Spike: peak=24.24305, time=5.727, d_freq=1352321279.38, chirp=-5.9821, fft_len=128k
Pulse: peak=5.91462, time=45.86, period=13.15, d_freq=1352325185.62, score=1.061, chirp=-8.9471, fft_len=1024
Pulse: peak=2.288693, time=45.84, period=3.867, d_freq=1352320459.77, score=1.002, chirp=-9.1617, fft_len=512
Pulse: peak=3.762485, time=45.86, period=9.015, d_freq=1352323815.94, score=1.004, chirp=-13.957, fft_len=1024
Spike: peak=24.19375, time=85.9, d_freq=1352327150.67, chirp=23.385, fft_len=128k
Spike: peak=24.54029, time=85.9, d_freq=1352327150.67, chirp=23.39, fft_len=128k
Pulse: peak=9.393847, time=46.17, period=28.63, d_freq=1352321706.07, score=1.02, chirp=38.231, fft_len=8k
Pulse: peak=3.339135, time=45.84, period=7.494, d_freq=1352328860.23, score=1, chirp=-40.942, fft_len=512
Pulse: peak=5.770851, time=45.86, period=13.69, d_freq=1352323539.85, score=1.034, chirp=46.311, fft_len=1024
Pulse: peak=1.297241, time=45.82, period=1.746, d_freq=1352326113.32, score=1.011, chirp=-60.411, fft_len=256
Pulse: peak=2.637341, time=45.9, period=4.593, d_freq=1352324522.16, score=1.029, chirp=74.726, fft_len=2k

Best spike: peak=26.40693, time=5.727, d_freq=1352321279.38, chirp=-5.9669, fft_len=128k
Best autocorr: peak=17.29339, time=28.63, delay=4.1283, d_freq=1352324638.74, chirp=-27.965, fft_len=128k
Best gaussian: peak=0, mean=0, ChiSq=0, time=-2.123e+11, d_freq=0,
score=-12, null_hyp=0, chirp=0, fft_len=0
Best pulse: peak=5.91462, time=45.86, period=13.15, d_freq=1352325185.62, score=1.061, chirp=-8.9471, fft_len=1024
Best triplet: peak=0, time=-2.123e+11, period=0, d_freq=0, chirp=0, fft_len=0


Flopcounter: 12534120800678.304688

Spike count: 9
Autocorr count: 0
Pulse count: 8
Triplet count: 0
Gaussian count: 0
Time cpu in use since last restart: 199.5 seconds
GPU device sync requested... ...GPU device synched
20:10:42 (89204): called boinc_finish(0)

</stderr_txt>
]]>

_________________________________________________________________________
Addicted to SETI crunching!
Founder of GPU Users Group
ID: 1821861 · Report as offensive
Profile -= Vyper =-
Volunteer tester
Avatar

Send message
Joined: 5 Sep 99
Posts: 1652
Credit: 1,065,191,981
RAC: 2,537
Sweden
Message 1821862 - Posted: 5 Oct 2016, 6:14:35 UTC
Last modified: 5 Oct 2016, 6:16:48 UTC

This host of mine has no errors as of yet. (EDIT: Those Three if you see them was me when i forgot to put the file in right directory)

"Consecutive valid tasks 2990"

http://setiathome.berkeley.edu/results.php?hostid=8053171

_________________________________________________________________________
Addicted to SETI crunching!
Founder of GPU Users Group
ID: 1821862 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1821917 - Posted: 5 Oct 2016, 10:30:58 UTC - in response to Message 1821861.  
Last modified: 5 Oct 2016, 10:33:31 UTC

I Found one!!!

Well, CUDA demonstrates some false positives in GPU code here but CPU re-processing seems did correction to zero number of triplets.
But what is worse - it showed overflow on spikes so invalid result overall.
It's not new that at some conditions CUDA builds get broken memory buffer and do false overflow as result. Usually this can be healed by host reboot.
Hardly outcome of this particular task is app-specific, more probably it's host-condition specific one. Can you re-run offline and check if overflow repeats?
SETI apps news
We're not gonna fight them. We're gonna transcend them.
ID: 1821917 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1821919 - Posted: 5 Oct 2016, 10:35:07 UTC - in response to Message 1821862.  

This host of mine has no errors as of yet. (EDIT: Those Three if you see them was me when i forgot to put the file in right directory)

"Consecutive valid tasks 2990"

http://setiathome.berkeley.edu/results.php?hostid=8053171


Validation inconclusive (164)
Quite impressive number. Is it OK enough or not OK - worth to check.
SETI apps news
We're not gonna fight them. We're gonna transcend them.
ID: 1821919 · Report as offensive
Profile -= Vyper =-
Volunteer tester
Avatar

Send message
Joined: 5 Sep 99
Posts: 1652
Credit: 1,065,191,981
RAC: 2,537
Sweden
Message 1821934 - Posted: 5 Oct 2016, 11:40:45 UTC - in response to Message 1821919.  
Last modified: 5 Oct 2016, 11:41:29 UTC

Yes i know. But the code cannot fix what the validator thinks primarly. All various offline mb wus is 99+% last when i spoke to Petri but that one that i found was clearly off the charts!

_________________________________________________________________________
Addicted to SETI crunching!
Founder of GPU Users Group
ID: 1821934 · Report as offensive
Profile -= Vyper =-
Volunteer tester
Avatar

Send message
Joined: 5 Sep 99
Posts: 1652
Credit: 1,065,191,981
RAC: 2,537
Sweden
Message 1821936 - Posted: 5 Oct 2016, 11:44:21 UTC - in response to Message 1821917.  

Can you re-run offline and check if overflow repeats?


I dont have the wu! But the machine is running nonstop 24/7 now and hasnt been rebooted or so. It has calculated more wus after the invalid one without reboot.

_________________________________________________________________________
Addicted to SETI crunching!
Founder of GPU Users Group
ID: 1821936 · Report as offensive
TBar
Volunteer tester

Send message
Joined: 22 May 99
Posts: 5204
Credit: 840,779,836
RAC: 2,768
United States
Message 1821993 - Posted: 5 Oct 2016, 16:18:10 UTC
Last modified: 5 Oct 2016, 16:18:39 UTC

I've managed to keep a GUPPI late overflow that consistently gives a false signal on most of the Apps I've tried it with. It runs for about 10 minutes then overflows. If someone wants it I could email it, or maybe post it at Crunchers Anonymous.

The tests on p_zi+ show it helps on the Mac, but it still gives many more inconclusive results than the original p_zi seen here, http://setiathome.berkeley.edu/results.php?hostid=7942417&offset=320 On the Linux 750Ti machine p_zi+ still doesn't stop the Invalid Overflows that happen occasionally with the older drivers and when running in Ubuntu 12.04.5 with driver 346.96 the App Stalled. So, it's back to the latest driver in Ubuntu and I suppose p_zi+ isn't much better than p_zi3i, which is the latest version of p_zi3 I have.
ID: 1821993 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1822023 - Posted: 5 Oct 2016, 21:13:43 UTC - in response to Message 1821993.  

Late overflows treated just as any overflows so don't represent interesting topic until validator changes will start.
I would concentrate on validity of non-overflows.
Test case I posted before (Richard has task downloaded) is example of such task.
Will it pass or fail with your latest build?
SETI apps news
We're not gonna fight them. We're gonna transcend them.
ID: 1822023 · Report as offensive
TBar
Volunteer tester

Send message
Joined: 22 May 99
Posts: 5204
Credit: 840,779,836
RAC: 2,768
United States
Message 1822033 - Posted: 5 Oct 2016, 21:41:30 UTC - in response to Message 1822023.  

Do you have a link to the WorkUnit?
ID: 1822033 · Report as offensive
Profile Raistmer
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 16 Jun 01
Posts: 6325
Credit: 106,370,077
RAC: 121
Russia
Message 1822038 - Posted: 5 Oct 2016, 22:04:20 UTC - in response to Message 1822033.  

Do you have a link to the WorkUnit?

http://setiathome.berkeley.edu/forum_thread.php?id=78569&postid=1820868
SETI apps news
We're not gonna fight them. We're gonna transcend them.
ID: 1822038 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14649
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1822042 - Posted: 5 Oct 2016, 22:19:31 UTC - in response to Message 1822033.  

Do you have a link to the WorkUnit?

It's often quite difficult to work out which previous report Raistmer is referring to, but I'm guessing it's his current favourite.

Beta WU 8902774

which was inconclusive when first reported two weeks ago (which is how I got hold of the data file), but has long since validated and had its files deleted.

Further references are in

Beta message 59657 (and several following)
Main message 1820868 (also with several following)

Petri's own computer running his own code mis-reported the final pulse (Beta message 59697), but he says his follow-up bench test didn't. Nobody has reproduced the failure, so the finger is pointing towards a hardware glitch, thermal event, etc.

But PM me an email address and I can send it over - it'll be tomorrow morning now, I'm on my way to bed.
ID: 1822042 · Report as offensive
Previous · 1 . . . 18 · 19 · 20 · 21 · 22 · 23 · 24 . . . 36 · Next

Message boards : Number crunching : Monitoring inconclusive GBT validations and harvesting data for testing


 
©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.