Monitoring inconclusive GBT validations and harvesting data for testing


Advanced search

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 . . . 26 · 27 · 28 · 29 · 30 · 31 · 32 . . . 36 · Next

AuthorMessage
Kiska
Volunteer tester

Send message
Joined: 31 Mar 12
Posts: 302
Credit: 3,067,762
RAC: 0
Australia
Message 1827404 - Posted: 29 Oct 2016, 21:37:49 UTC - in response to Message 1827297.  
Last modified: 29 Oct 2016, 21:38:34 UTC

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.

Workunit 2304111745 (blc3_2bit_guppi_57432_27257_HIP57494_0009.15810.831.18.27.104.vlar)
Task 5239674006 (S=20, A=0, P=10, T=0, G=0) SSE3xj Win32 Build 3528
Task 5239674007 (S=18, A=0, P=12, T=0, G=0) v8.19 (opencl_nvidia_SoG) windows_intelx86
Task 5242168321 (S=20, A=0, P=10, T=0, G=0) v8.19 (opencl_nvidia_SoG) windows_intelx86
Task 5244395277 (S=19, A=0, P=11, T=0, G=0) v8.19 (opencl_nvidia_SoG) windows_intelx86
Task 5245993619 (S=21, A=0, P=9, T=0, G=0) SSE2xj Win32 Build 3500

The sixth host looks like it will be running stock Windows CPU.

The interesting thing about that WU is that the first four tasks all used exactly the same application - NV SoG r3528.

Jeff has his anonymous platform deployment tuned up with a command line, but the other three are all operating in default mode. And there's not a great deal of difference in the GPUs either - GTXs 960, 980, 760, 760 Ti OEM respectively. I'm getting a hint of overclocking from the 980 (Max clock 1367Mhz feels a bit toasty, and it has a previous invalid) - but why can't the other three come up with a matched pair between them?


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
ID: 1827404 · 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 1827408 - Posted: 29 Oct 2016, 22:10:58 UTC - in response to Message 1827386.  
Last modified: 29 Oct 2016, 22:12:44 UTC

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.
ID: 1827408 · Report as offensive
TBar
Volunteer tester

Send message
Joined: 22 May 99
Posts: 5204
Credit: 840,779,836
RAC: 2,768
United States
Message 1827414 - Posted: 29 Oct 2016, 22:31:58 UTC - in response to Message 1827408.  

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...
ID: 1827414 · 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 1827415 - Posted: 29 Oct 2016, 22:38:56 UTC - in response to Message 1827414.  

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.
ID: 1827415 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14650
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1827416 - Posted: 29 Oct 2016, 22:44:11 UTC - in response to Message 1827404.  

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
ID: 1827416 · Report as offensive
TBar
Volunteer tester

Send message
Joined: 22 May 99
Posts: 5204
Credit: 840,779,836
RAC: 2,768
United States
Message 1827420 - Posted: 29 Oct 2016, 23:07:48 UTC - in response to Message 1827415.  

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.

OK, but, the SoG build doesn't use ASYNC_SPIKE...and it has the same Error.
ID: 1827420 · Report as offensive
TBar
Volunteer tester

Send message
Joined: 22 May 99
Posts: 5204
Credit: 840,779,836
RAC: 2,768
United States
Message 1827435 - Posted: 30 Oct 2016, 0:52:02 UTC - in response to Message 1827415.  

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?
ID: 1827435 · Report as offensive
Profile Jeff Buck Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester

Send message
Joined: 11 Feb 00
Posts: 1441
Credit: 148,764,870
RAC: 0
United States
Message 1827441 - Posted: 30 Oct 2016, 2:02:16 UTC - in response to Message 1827404.  

I decided to test this using stock CPU app and SoG on my machine in offline mode.

This is rescmpv result of Q100:

Result : Weakly similar.

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.
ID: 1827441 · Report as offensive
Profile Wiggo
Avatar

Send message
Joined: 24 Jan 00
Posts: 34744
Credit: 261,360,520
RAC: 489
Australia
Message 1827443 - Posted: 30 Oct 2016, 2:18:41 UTC

I decided to test this using stock CPU app and SoG on my machine in offline mode.

This is rescmpv result of Q100:

Result : Weakly similar.

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.

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.
ID: 1827443 · Report as offensive
Profile Jeff Buck Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester

Send message
Joined: 11 Feb 00
Posts: 1441
Credit: 148,764,870
RAC: 0
United States
Message 1827452 - Posted: 30 Oct 2016, 3:38:41 UTC
Last modified: 30 Oct 2016, 4:26:56 UTC

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.
ID: 1827452 · 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 1827467 - Posted: 30 Oct 2016, 6:15:49 UTC - in response to Message 1827452.  
Last modified: 30 Oct 2016, 6:25:38 UTC



Both hosts seem to have clean records when it comes to Invalids.

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.
ID: 1827467 · 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 1827469 - Posted: 30 Oct 2016, 6:39:45 UTC - in response to Message 1827435.  

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.


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.
ID: 1827469 · 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 1827470 - Posted: 30 Oct 2016, 6:42:15 UTC - in response to Message 1827420.  

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.

OK, but, the SoG build doesn't use ASYNC_SPIKE...and it has the same Error.

Examples of crash with SoG build?
SETI apps news
We're not gonna fight them. We're gonna transcend them.
ID: 1827470 · 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 1827473 - Posted: 30 Oct 2016, 7:23:56 UTC

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.
ID: 1827473 · Report as offensive
Kiska
Volunteer tester

Send message
Joined: 31 Mar 12
Posts: 302
Credit: 3,067,762
RAC: 0
Australia
Message 1827482 - Posted: 30 Oct 2016, 8:31:27 UTC - in response to Message 1827452.  
Last modified: 30 Oct 2016, 9:12:21 UTC

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.


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
ID: 1827482 · Report as offensive
Kiska
Volunteer tester

Send message
Joined: 31 Mar 12
Posts: 302
Credit: 3,067,762
RAC: 0
Australia
Message 1827490 - Posted: 30 Oct 2016, 10:01:49 UTC - in response to Message 1827473.  
Last modified: 30 Oct 2016, 10:03:17 UTC

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
ID: 1827490 · 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 1827491 - Posted: 30 Oct 2016, 10:33:39 UTC - in response to Message 1827490.  
Last modified: 30 Oct 2016, 10:35:28 UTC


You can find the result files and data files here

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.
ID: 1827491 · Report as offensive
Kiska
Volunteer tester

Send message
Joined: 31 Mar 12
Posts: 302
Credit: 3,067,762
RAC: 0
Australia
Message 1827493 - Posted: 30 Oct 2016, 10:44:11 UTC - in response to Message 1827491.  


You can find the result files and data files here

Conclusion?
Seems it validates OK.
Try other overflows.
And I would like see vaidation for r3528 in the same area for the same task.


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%
ID: 1827493 · 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 1827494 - Posted: 30 Oct 2016, 10:51:22 UTC - in response to Message 1827493.  

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.
ID: 1827494 · Report as offensive
Kiska
Volunteer tester

Send message
Joined: 31 Mar 12
Posts: 302
Credit: 3,067,762
RAC: 0
Australia
Message 1827495 - Posted: 30 Oct 2016, 10:57:18 UTC - in response to Message 1827494.  

Thanks.
Would be good to check other collected so far overflows.
In the same result representation.


If you are patient enough, I can produce 1 more in the next 2 hours
ID: 1827495 · Report as offensive
Previous · 1 . . . 26 · 27 · 28 · 29 · 30 · 31 · 32 . . . 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.