Message boards :
Number crunching :
Monitoring inconclusive GBT validations and harvesting data for testing
Message board moderation
Previous · 1 . . . 26 · 27 · 28 · 29 · 30 · 31 · 32 . . . 36 · Next
Author | Message |
---|---|
Kiska Send message Joined: 31 Mar 12 Posts: 302 Credit: 3,067,762 RAC: 0 |
I refrained from posting this one when it was just a quadruple, a couple days ago, but now that it's become a quintuple Inconclusive, I think it merits some publicity. I decided to test this using stock CPU app and SoG on my machine in offline mode. This is rescmpv result of Q100: C:\Users\qingb\Documents\TestEnvironment>compare GPUResult.sah CPUResult.sah Q100 ------------- R1:R2 ------------ ------------- R2:R1 ------------ Exact Super Tight Good Bad Exact Super Tight Good Bad Spike 0 20 20 20 0 0 20 20 20 1 Gaussian 0 0 0 0 0 0 0 0 0 0 Pulse 0 9 9 9 1 0 9 9 9 0 Triplet 0 0 0 0 0 0 0 0 0 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 ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- 0 29 29 29 1 0 29 29 29 1 Unmatched signal(s) in R1 at line(s) 676 Unmatched signal(s) in R2 at line(s) 884 For R1:R2 matched signals only, Q= 99.99% Result : Weakly similar. GPU is GT 840m and CPU is i5-4210U |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
Remove ASYNC_SPIKES. I don't use this path in recent builds so compatibility with latest revs not checked. And why x64 ? Do you use x64 always? Windows GPU builds all x86 ones. 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 |
Macs have been all 64 bit for a while, so yes, always use 64 bit. Never had this problem before. From my understanding, it's trying to free the same memory space twice. I've looked at malloc_a.cpp but don't see what I'm looking for. Not really sure about what I'm looking for... |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
Macs have been all 64 bit for a while, so yes, always use 64 bit. Never had this problem before. From my understanding, it's trying to free the same memory space twice. I've looked at malloc_a.cpp but don't see what I'm looking for. Not really sure about what I'm looking for... Build w/o ASYNC_SPIKE then will see. 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 |
I decided to test this using stock CPU app and SoG on my machine in offline mode. C:\Users\qingb\Documents\TestEnvironment>compare GPUResult.sah CPUResult.sah Q100 ------------- R1:R2 ------------ ------------- R2:R1 ------------ Exact Super Tight Good Bad Exact Super Tight Good Bad Spike 0 20 20 20 0 0 20 20 20 1 Gaussian 0 0 0 0 0 0 0 0 0 0 Pulse 0 9 9 9 1 0 9 9 9 0 Triplet 0 0 0 0 0 0 0 0 0 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 ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- 0 29 29 29 1 0 29 29 29 1 Unmatched signal(s) in R1 at line(s) 676 Unmatched signal(s) in R2 at line(s) 884 For R1:R2 matched signals only, Q= 99.99% Result : Weakly similar. GPU is GT 840m and CPU is i5-4210U |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
Macs have been all 64 bit for a while, so yes, always use 64 bit. Never had this problem before. From my understanding, it's trying to free the same memory space twice. I've looked at malloc_a.cpp but don't see what I'm looking for. Not really sure about what I'm looking for... OK, but, the SoG build doesn't use ASYNC_SPIKE...and it has the same Error. |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
Build w/o ASYNC_SPIKE then will see. I may have found part of the problem. It appears this code doesn't like the malloc.h file from the Apple SDK. By leaving that out the NV build didn't crash...yet. The NV build is still much slower than the Intel build though. Starting benchmark run... --------------------------------------------------- Listing wu-file(s) in /testWUs : blc6_2bit_guppi_57397_MESSIER031_0004.10283.831.23.46.140.wu reference_work_unit_r3215.wu Listing executable(s) in /APPS : MBv8_8.18r3548_NV_ssse3_x86_64-apple-darwin Listing executable in /REF_APPs : MBv8_8.05r3344_sse41_x86_64-apple-darwin --------------------------------------------------- Current WU: blc6_2bit_guppi_57397_MESSIER031_0004.10283.831.23.46.140.wu --------------------------------------------------- Skipping default app MBv8_8.05r3344_sse41_x86_64-apple-darwin, displaying saved result(s) Elapsed Time: ………………………………… 5898 seconds --------------------------------------------------- Running app with command : MBv8_8.18r3548_NV_ssse3_x86_64-apple-darwin -sbs 192 -oclfft_tune_wg 128 -spike_fft_thresh 2048 -period_iterations_num 8 -device 2 1343.46 real 147.56 user 235.97 sys Elapsed Time : ……………………………… 1344 seconds Speed compared to default : 438 % ----------------- Comparing results Result : Strongly similar, Q= 99.86% --------------------------------------------------- Done with blc6_2bit_guppi_57397_MESSIER031_0004.10283.831.23.46.140.wu. Current WU: reference_work_unit_r3215.wu --------------------------------------------------- Skipping default app MBv8_8.05r3344_sse41_x86_64-apple-darwin, displaying saved result(s) Elapsed Time: ………………………………… 2521 seconds --------------------------------------------------- Running app with command : MBv8_8.18r3548_NV_ssse3_x86_64-apple-darwin -sbs 192 -oclfft_tune_wg 128 -spike_fft_thresh 2048 -period_iterations_num 8 -device 2 480.29 real 103.45 user 103.00 sys Elapsed Time : ……………………………… 480 seconds Speed compared to default : 525 % ----------------- Comparing results Result : Strongly similar, Q= 99.51% --------------------------------------------------- Current WU: blc6_2bit_guppi_57397_MESSIER031_0004.10283.831.23.46.140.wu --------------------------------------------------- Skipping default app MBv8_8.05r3344_sse41_x86_64-apple-darwin, displaying saved result(s) Elapsed Time: ………………………………… 5898 seconds --------------------------------------------------- Running app with command : MBv8_8.18r3550_Intel_ssse3_x86_64-apple-darwin -sbs 192 -oclfft_tune_wg 128 -spike_fft_thresh 2048 -period_iterations_num 8 -device 2 927.81 real 134.74 user 244.77 sys Elapsed Time : ……………………………… 928 seconds Speed compared to default : 635 % ----------------- Comparing results Result : Strongly similar, Q= 99.86% --------------------------------------------------- Done with blc6_2bit_guppi_57397_MESSIER031_0004.10283.831.23.46.140.wu. Current WU: reference_work_unit_r3215.wu --------------------------------------------------- Skipping default app MBv8_8.05r3344_sse41_x86_64-apple-darwin, displaying saved result(s) Elapsed Time: ………………………………… 2521 seconds --------------------------------------------------- Running app with command : MBv8_8.18r3550_Intel_ssse3_x86_64-apple-darwin -sbs 192 -oclfft_tune_wg 128 -spike_fft_thresh 2048 -period_iterations_num 8 -device 2 319.48 real 105.15 user 86.01 sys Elapsed Time : ……………………………… 320 seconds Speed compared to default : 787 % ----------------- Comparing results Result : Strongly similar, Q= 99.51% --------------------------------------------------- So, why is the Intel build faster on the nVidia cards? |
Jeff Buck Send message Joined: 11 Feb 00 Posts: 1441 Credit: 148,764,870 RAC: 0 |
I decided to test this using stock CPU app and SoG on my machine in offline mode. That appears to be the same conclusion that the validator reached. The final host, running stock CPU, validated against the 5th host, running r3500 on an ATI GPU, which was awarded the canonical result. The 4 Nvidia SoG hosts must have qualified as weakly similar since all 6 hosts got 75.56 credits for their troubles. |
Wiggo Send message Joined: 24 Jan 00 Posts: 36269 Credit: 261,360,520 RAC: 489 |
I decided to test this using stock CPU app and SoG on my machine in offline mode. I've even noticed the disparity between the SoG apps running on similar Nvidia hardware and I totally agree with Richard that a lot more work is needed on that app to get a better consistency happening. It's rough when 4 similar Nvidia SoG setups can't agree on results for a single w/u and this is happening a lot since I changed over to start testing this app (my inconclusives have also increased by 50% since changing over to SoG from CUDA). Cheers. |
Jeff Buck Send message Joined: 11 Feb 00 Posts: 1441 Credit: 148,764,870 RAC: 0 |
With no new quadruple or quintuple Inconclusives in my list this evening, I just sort of skimmed through and found a simple non-overflow WU that caught my eye as perhaps being worth a further look. Workunit 2304221226 (21jl16aa.27457.19699.15.42.98) Task 5239912411 (S=5, A=1, P=1, T=0, G=0) v8.00 windows_intelx86 Task 5239912412 (S=7, A=1, P=1, T=0, G=0) v8.19 (opencl_nvidia_SoG) windows_intelx86 Stock CPU and stock Nvidia SoG disagree on the Spike count and, while tho CPU app obviously doesn't show the signal detail, the SoG detail shows a couple of Spikes that look awfully suspicious to me, and seem likely to be the two extras that SoG found. Spike: peak=24.65532, time=16.78, d_freq=1420954251.53, chirp=0.23661, fft_len=64k Spike: peak=24.12827, time=105.7, d_freq=1420958973.29, chirp=0.93165, fft_len=32k Spike: peak=24.75678, time=105.7, d_freq=1420958973.29, chirp=0.99081, fft_len=32k Spike: peak=24.06635, time=105.7, d_freq=1420958973.28, chirp=1.05, fft_len=32k Autocorr: peak=18.04306, time=33.55, delay=6.2671, d_freq=1420956661.79, chirp=-11.011, fft_len=128k Pulse: peak=7.364211, time=18.11, period=2.901, d_freq=1420954170.74, score=1.022, chirp=23.193, fft_len=512 Spike: peak=171.9809, time=6.711, d_freq=1420961727.96, chirp=-16.996, fft_len=128k Spike: peak=423.1836, time=6.711, d_freq=1420961545.11, chirp=-16.998, fft_len=128k Spike: peak=24.11409, time=100.7, d_freq=1420953568.29, chirp=-29.569, fft_len=128k Both hosts seem to have clean records when it comes to Invalids. My host is currently running the potential tie-breaker as Cuda50. It should probably be done in about 45 minutes or so. I've already grabbed the WU and will try to catch the result file if I can. EDIT: Okay, my host finished the task and, as I suspected, it agreed with the stock CPU app, with no sign of those two wild Spikes. The SoG host also validated, though. I've zipped up the WU file and my Cuda50 result file and uploaded it to Amazon as WU2304221226.zip, for anyone who wants to take a further look. |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
http://setiathome.berkeley.edu/results.php?hostid=7940818&offset=0&show_names=0&state=3&appid= such number of inconclusives (and first few checked are non-overflows) can't be considered as "clean records". Smth. wrong on that host. BTW, its other inconclusives also have too big Spike on 128k fft. And another observation - through that inconclusives list driver version changes. 372.70, 372.90. Maybe inconsistent dirver update results in such behavior. Most of inconclusives are from 28 & 29 October. Only 5 from dates earlier than 24 Oct. And per 24Oct host had bigger driver version: Driver version: 375.57 So, I would attribute its breakage to incorrect driver re-installation. 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 |
Build w/o ASYNC_SPIKE then will see. So, diffrent SDKs used for iGPU and NV builds? Then try to build NV app with Intel's SDK completely. 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 |
Macs have been all 64 bit for a while, so yes, always use 64 bit. Never had this problem before. From my understanding, it's trying to free the same memory space twice. I've looked at malloc_a.cpp but don't see what I'm looking for. Not really sure about what I'm looking for... Examples of crash with SoG build? 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 |
Try this build on collected overflows offline: https://cloud.mail.ru/public/2zrS/j29thqscP. Will it agree with CPU more? SETI apps news We're not gonna fight them. We're gonna transcend them. |
Kiska Send message Joined: 31 Mar 12 Posts: 302 Credit: 3,067,762 RAC: 0 |
With no new quadruple or quintuple Inconclusives in my list this evening, I just sort of skimmed through and found a simple non-overflow WU that caught my eye as perhaps being worth a further look. I have ran this workunit with my GT840m running SoG r3528 C:\Users\qingb\Documents\TestEnvironment>compare GT840m.sah cuda50.sah Q100 ------------- R1:R2 ------------ ------------- R2:R1 ------------ Exact Super Tight Good Bad Exact Super Tight Good Bad Spike 0 5 5 5 0 0 5 5 5 0 Autocorr 0 1 1 1 0 0 1 1 1 0 Gaussian 0 0 0 0 0 0 0 0 0 0 Pulse 0 1 1 1 0 0 1 1 1 0 Triplet 0 0 0 0 0 0 0 0 0 0 Best Spike 0 1 1 1 0 0 1 1 1 0 Best Autocorr 0 1 1 1 0 0 1 1 1 0 Best Gaussian 0 1 1 1 0 0 1 1 1 0 Best Pulse 0 1 1 1 0 0 1 1 1 0 Best Triplet 0 0 0 0 0 0 0 0 0 0 ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- 0 11 11 11 0 0 11 11 11 0 Result : Strongly similar, Q= 99.96% EDIT: I have no idea now to format this correctly EDIT2: Fixed |
Kiska Send message Joined: 31 Mar 12 Posts: 302 Credit: 3,067,762 RAC: 0 |
Try this build on collected overflows offline: https://cloud.mail.ru/public/2zrS/j29thqscP. Will it agree with CPU more? r3548 produces: C:\Users\qingb\Documents\TestEnvironment>compare CPUResult.sah GT840m_r3548.sah Q100 ------------- R1:R2 ------------ ------------- R2:R1 ------------ Exact Super Tight Good Bad Exact Super Tight Good Bad Spike 0 21 21 21 0 0 21 21 21 0 Gaussian 0 0 0 0 0 0 0 0 0 0 Pulse 0 9 9 9 0 0 9 9 9 0 Triplet 0 0 0 0 0 0 0 0 0 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 ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- 0 30 30 30 0 0 30 30 30 0 Result : Strongly similar, Q= 99.99% You can find the result files and data files here |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
Conclusion? Seems it validates OK. Try other overflows. And I would like see vaidation for r3528 in the same area for the same task. SETI apps news We're not gonna fight them. We're gonna transcend them. |
Kiska Send message Joined: 31 Mar 12 Posts: 302 Credit: 3,067,762 RAC: 0 |
I had already ran it but here it is again: C:\Users\qingb\Documents\TestEnvironment>compare CPUResult.sah GT840m_r3528.sah Q100 ------------- R1:R2 ------------ ------------- R2:R1 ------------ Exact Super Tight Good Bad Exact Super Tight Good Bad Spike 0 20 20 20 1 0 20 20 20 0 Gaussian 0 0 0 0 0 0 0 0 0 0 Pulse 0 9 9 9 0 0 9 9 9 1 Triplet 0 0 0 0 0 0 0 0 0 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 ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- 0 29 29 29 1 0 29 29 29 1 Unmatched signal(s) in R1 at line(s) 884 Unmatched signal(s) in R2 at line(s) 676 For R1:R2 matched signals only, Q= 99.99% Result : Weakly similar. C:\Users\qingb\Documents\TestEnvironment>compare CPUResult.sah GT840m_r3548.sah Q100 ------------- R1:R2 ------------ ------------- R2:R1 ------------ Exact Super Tight Good Bad Exact Super Tight Good Bad Spike 0 21 21 21 0 0 21 21 21 0 Gaussian 0 0 0 0 0 0 0 0 0 0 Pulse 0 9 9 9 0 0 9 9 9 0 Triplet 0 0 0 0 0 0 0 0 0 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 ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- 0 30 30 30 0 0 30 30 30 0 Result : Strongly similar, Q= 99.99% |
Raistmer Send message Joined: 16 Jun 01 Posts: 6325 Credit: 106,370,077 RAC: 121 |
Thanks. Would be good to check other collected so far overflows. In the same result representation. SETI apps news We're not gonna fight them. We're gonna transcend them. |
Kiska Send message Joined: 31 Mar 12 Posts: 302 Credit: 3,067,762 RAC: 0 |
Thanks. If you are patient enough, I can produce 1 more in the next 2 hours |
©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.