Message boards :
Number crunching :
Monitoring inconclusive GBT validations and harvesting data for testing
Message board moderation
Previous · 1 . . . 18 · 19 · 20 · 21 · 22 · 23 · 24 . . . 36 · Next
Author | Message |
---|---|
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
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. |
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
Overflow results may not be useless. 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. |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
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. |
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
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. |
petri33 Send message Joined: 6 Jun 02 Posts: 1668 Credit: 623,086,772 RAC: 156 |
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 |
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
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. 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. |
Mark Stevenson Send message Joined: 8 Sep 11 Posts: 1736 Credit: 174,899,165 RAC: 91 |
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 !!;-) |
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
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) 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. |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
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. |
-= Vyper =- Send message Joined: 5 Sep 99 Posts: 1652 Credit: 1,065,191,981 RAC: 2,537 |
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 |
-= Vyper =- Send message Joined: 5 Sep 99 Posts: 1652 Credit: 1,065,191,981 RAC: 2,537 |
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 |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
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. |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
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) 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. |
-= Vyper =- Send message Joined: 5 Sep 99 Posts: 1652 Credit: 1,065,191,981 RAC: 2,537 |
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 |
-= Vyper =- Send message Joined: 5 Sep 99 Posts: 1652 Credit: 1,065,191,981 RAC: 2,537 |
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 |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
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. |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
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. |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
Do you have a link to the WorkUnit? |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
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. |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14672 Credit: 200,643,578 RAC: 874 |
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. |
©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.