+- +-
Say hello if visiting :) by Gecko
11 Jan 2023, 07:43:05 pm

Seti is down again by Mike
09 Aug 2017, 10:02:44 am

Some considerations regarding OpenCL MultiBeam app tuning from algorithm view by Raistmer
11 Dec 2016, 06:30:56 am

Loading APU to the limit: performance considerations by Mike
05 Nov 2016, 06:49:26 am

Better sleep on Windows - new round by Raistmer
26 Aug 2016, 02:02:31 pm

Author Topic: x38g reports  (Read 126875 times)

Offline SciManStev

  • Alpha Tester
  • Knight Templar
  • ***
  • Posts: 263
Re: x38g reports
« Reply #105 on: 29 Jun 2011, 06:09:21 pm »
Here is x39a, x39d, and x39e V6. I have been running 3 wu's at a time with x39a live without issues. I have only had one invalid wu, out of thousands. Driver 275.33

Steve

Offline Jason G

  • Construction Fraggle
  • Knight who says 'Ni!'
  • *****
  • Posts: 8980
Re: x38g reports
« Reply #106 on: 29 Jun 2011, 06:11:28 pm »
Here is x39a, x39d, and x39e V6. I have been running 3 wu's at a time with x39a live without issues. I have only had one invalid wu, out of thousands. Driver 275.33

Steve

Thanks Steve, yeah it's these 460's (and some others) that appear to be sensitive to something I'm abusing.  We seem to be home 'n hosed with the 480s

Offline SciManStev

  • Alpha Tester
  • Knight Templar
  • ***
  • Posts: 263
Re: x38g reports
« Reply #107 on: 29 Jun 2011, 06:20:01 pm »
That's what I gathered by reading the threads, but I wanted to throw in a test or two myself. Is there any particular app you would like me to run live, or is there any other comparison you would like me to run?

Steve

PS. I did back down my BCLK one click and eliminated my AP invalids.

Offline Jason G

  • Construction Fraggle
  • Knight who says 'Ni!'
  • *****
  • Posts: 8980
Re: x38g reports
« Reply #108 on: 29 Jun 2011, 06:20:29 pm »
x39e all the way  ;D

Offline SciManStev

  • Alpha Tester
  • Knight Templar
  • ***
  • Posts: 263
Re: x38g reports
« Reply #109 on: 29 Jun 2011, 06:25:40 pm »
Done!

Steve

Offline Jason G

  • Construction Fraggle
  • Knight who says 'Ni!'
  • *****
  • Posts: 8980
Re: x38g reports
« Reply #110 on: 29 Jun 2011, 06:45:56 pm »
Manual 27fe11ac.12560.9065.8.10.100  result cross comparison under bench conditions

Claggy's x39e (GTX460) Vs my x39e(GTX480) under bench conditions:  Strongly similar,  Q= 99.95%
My x39e (GTX 480) Vs AKv8bx64SSSE3x:  Result      : Strongly similar,  Q= 99.74%
Claggy's x38g (GTX 460) Vs x39e(My GTX 480): Result      : Strongly similar,  Q= 99.97%
Claggy's x32f (GTX 460) Vs AKv8b( My e8400): Weakly similar. (Bodgy Best Gaussian)
Claggy's x32f (GTX 460) Vs   x39e(My GTX 480): Weakly similar. (Bodgy Best Gaussian)

Tentative analysis:  The known CPU app spikes issues are playing no part here.  The bodgy best Gaussian is in x32f due to innacurate stock nVidia chirp ( ~48 bit precision emulated floating point), I've kept complete documentation on how I fixed that chirp in the alpha ivory beer tower.    x32f & the stock code it came from are crap with highly chirp sensitive signals.

On the live runs, the x38g result likely didn't match the x39d result purely due to the known stability issues we are here to resolve on that class of card.

AKv8b found here:
Quote
Spike count:    8
Pulse count:    4
Triplet count:  0
Gaussian count: 2

with the live run CPU 6.03 guy finding:
Quote
Spike count:    8
Pulse count:    4
Triplet count:  0
Gaussian count: 3

Now A stock cuda 6.08 wingman has rocked up, STILL INONCLUSIVE....LoL... ;D
Quote
Spike count:    8
Pulse count:    4
Triplet count:  0
Gaussian count: 2

IMO, all the results are broken in some way apart from the offline AKv8b ones & the x39d/e results.
Jason
« Last Edit: 29 Jun 2011, 07:14:17 pm by Jason G »

Offline Claggy

  • Alpha Tester
  • Knight who says 'Ni!'
  • ***
  • Posts: 3111
    • My computers at Seti Beta
Re: x38g reports
« Reply #111 on: 29 Jun 2011, 06:59:00 pm »
Here's the results of the 9800GTX+ run, all apps Strongly similar,

Claggy
« Last Edit: 29 Jun 2011, 07:01:11 pm by Claggy »

Offline Jason G

  • Construction Fraggle
  • Knight who says 'Ni!'
  • *****
  • Posts: 8980
Re: x38g reports
« Reply #112 on: 29 Jun 2011, 07:09:10 pm »
Well, unfortunately the 9800 result has the stock-x32f-style bodgy gaussian against AKv8b so there will be something to look at deeper with the pre-Fermis  (That gaussian drift against CPU results has been there for a long time though)
« Last Edit: 29 Jun 2011, 07:15:31 pm by Jason G »

Offline perryjay

  • Knight Templar
  • ****
  • Posts: 427
Re: x38g reports
« Reply #113 on: 29 Jun 2011, 07:29:49 pm »
And here I thought I was just going to show something kinda interesting. I didn't know I was gonna start all this!   :o

Offline arkayn

  • Janitor o' the Board
  • Knight who says 'Ni!'
  • *****
  • Posts: 1230
  • Aaaarrrrgggghhhh
    • My Little Place On The Internet
Re: x38g reports
« Reply #114 on: 29 Jun 2011, 07:47:12 pm »
I thought it was the 560's having problems, I have not seen any problems from my little 460.

Offline Claggy

  • Alpha Tester
  • Knight who says 'Ni!'
  • ***
  • Posts: 3111
    • My computers at Seti Beta
Re: x38g reports
« Reply #115 on: 29 Jun 2011, 07:50:09 pm »
I thought it was the 560's having problems, I have not seen any problems from my little 460.
I think the 560's just have bigger problems,

Claggy

Offline Jason G

  • Construction Fraggle
  • Knight who says 'Ni!'
  • *****
  • Posts: 8980
Re: x38g reports
« Reply #116 on: 29 Jun 2011, 11:11:29 pm »
I thought it was the 560's having problems, I have not seen any problems from my little 460.
I think the 560's just have bigger problems,
and not all 460's & 560's are created equal either, whereas 480's like mine & Steve's are nVidia reference & likely as close to identical as they come, so relatively predictable.  It's something that should not reflect in the results when the code is 100% 'right'. 

Since some of the newer code in play is specifically written to exploit the superscaler instruction level parallelism for maximum bandwidth on compute capabiiity 2.1, i.e 48 instead of 32 Cuda cores per multiprocessor with an extra warp scheduler, if somethings' being pushed to the limits kernel execution configuration wise then It;s going to show on those cards with harder constraints first.

Jason

Offline Josef W. Segur

  • Janitor o' the Board
  • Knight who says 'Ni!'
  • *****
  • Posts: 3112
Re: x38g reports
« Reply #117 on: 30 Jun 2011, 01:16:02 am »
Hmm, I noticed the "Bodgy Best Gaussian" occurred at chirp rate ~63.9958 and the presumably correct one at ~79.3237. So while running the WU with stock 6.95 I periodically checked state.sah to see what would turn up near those rates. Before the first there was a fairly weak "best" captured at chirp -15.88619 with a score of 0.125732, then the bodgy with a score of 1.293129, and the final one had a score of 1.305961. I don't know how to evaluate the 0.98% difference between bodgy and final scores.

AK_v8b_win_SSSE3x.exe has just gotten to bodgy and calculates its score as 1.293091 which is close though I'd rather the first difference were in the 6th significant digit than the 5th.
                                                                  Joe

Offline Jason G

  • Construction Fraggle
  • Knight who says 'Ni!'
  • *****
  • Posts: 8980
Re: x38g reports
« Reply #118 on: 30 Jun 2011, 01:36:48 am »
AK_v8b_win_SSSE3x.exe has just gotten to bodgy and calculates its score as 1.293091 which is close though I'd rather the first difference were in the 6th significant digit than the 5th.

If you are too, I'm content to call this one "remaining chirp annoyances, with added yet to be divined nVidia Gaussfit implementation vagaries"

Offline Jason G

  • Construction Fraggle
  • Knight who says 'Ni!'
  • *****
  • Posts: 8980
Re: x38g reports
« Reply #119 on: 30 Jun 2011, 02:00:29 am »
I don't know how to evaluate the 0.98% difference between bodgy and final scores.

Just a naive thought on how that could interact with slight chirp differences:  If you take a fairly 'phat' gaussian (wider bandwidth bin leakage or similar effect) then stride it in slightly different angles, you will get a slightly different fit (shape)  for very similar (but not the same) peak... could there be some substantial aliasing & could [recommending to the project] some windowed transforms improve that SNR (controlling 'lobing' in the frequency domain)?
« Last Edit: 30 Jun 2011, 02:04:19 am by Jason G »

 

Welcome, Guest.
Please login or register.
 
 
 
Forgot your password?
Members
Total Members: 97
Latest: ToeBee
New This Month: 0
New This Week: 0
New Today: 0
Stats
Total Posts: 59559
Total Topics: 1672
Most Online Today: 226
Most Online Ever: 983
(20 Jan 2020, 03:17:55 pm)
Users Online
Members: 0
Guests: 22
Total: 22
Powered by EzPortal