CCminer(SP-MOD) Modded GPU kernels.

[sp_]

INITIAL RESULTS--

I cloned git commit #725 and ran it on my 2 rigs.  THE "...does not validate on CPU" ERRORS are GONE!  The hash rate still fluctuates.  Hash rate is printed to the screen only with the physical GPU number.  Using only "-g 4" and default intensity (no -i flag used), the 8 threads on my 2-card rig are reported at launch, as are the 24 threads on my 6 card rig.  Then the hash rate fluctuates to higher than normal values, but without error.  My 2-card 970 FTW+ rig is averaging near 35Mh/s, and my 6-card 750ti FTW rig is averaging around 60Mh/s.  Both rig's hash rates swing wildly.  

My total rate for all three machines mining on yaamp was about 80Mh/s before, mining with single threads as reported on the previous page.  This was reflected in the pool rate.  The pool rate still remains at the same level with commit #725, but the errors are gone.  The local rates total over 100Mh/s, including a steady, single-threaded, rate for my 960 SSC of about 9.4Mh/s.  The 960 SSC is somewhat like a control sample, I suppose.       --scryptr

The stats have been corrected now, the miner should display around 70-80Mh/s (wich is the rate you get at the pool). Perhaps a bit more if you play with the -g and the -i parameter.

[totoy]

Yeah, I definitely won't be able to do it with these instructions...
If anybody has step by step ones I'll try.

here http://cryptomining-blog.com/tag/compile-cudaminer-for-windows/

[chrysophylax]

Fixed now . The new blake was missing a cpu_init call

tanx sp ...

new clone then compile ...

will let you know how it goes in a few minutes ...

#crysx

all compiled and seems good so far sp ...

testing x11 at the moment - but will test on quark later today and see how it goes ...

tanx ...

edit ...

testing quark now ... seems to be stable so far and a higher hashrate ...

-g 3 -i 22 on gigabyte 750ti oc lp ... stock clocks ... westhash ...

[2015-04-24 16:49:49] GPU #1: GeForce GTX 750 Ti, 5395
[2015-04-24 16:49:49] GPU #1: GeForce GTX 750 Ti, 6080
[2015-04-24 16:49:49] GPU #0: GeForce GTX 750 Ti, 6641
[2015-04-24 16:49:50] GPU #1: GeForce GTX 750 Ti, 5518
[2015-04-24 16:49:50] GPU #0: GeForce GTX 750 Ti, 6209
[2015-04-24 16:49:50] GPU #0: GeForce GTX 750 Ti, 5486
[2015-04-24 16:49:52] GPU #1: GeForce GTX 750 Ti, 5951
[2015-04-24 16:49:52] accepted: 24/24 (100.00%), 11444 khash/s yay!!!
[2015-04-24 16:49:55] stratum.westhash.com:3345/ quark block 1563963

#crysx

[sp_]

-g 4  -i 23 gave higher rate, but crashed the rig after a while (2x750ti)

How is the power consumption, is it up with more gpu threads?

-g 5 is also working, but a bit slower.

[chrysophylax]

-g 4  -i 23 gave higher rate, but crashed the rig after a while (2x750ti)

How is the power consumption, is it up with more gpu threads?

-g 5 is also working, but a bit slower.

im not too sure at the moment mate ...

ive lost remote ( ssh ) access for some reason and because im not there - i cant read the power meter ...

cant wait till i can do this full time - and fix all these little shitty issues ...

ill let you know when i can either 1 - get access to the farm or 2 - physically go there tonight and fix this issue ...

the test machine is on westhash at the moment if you want to have a look at -g3 -i 22 parameters with quark - two gisgabyte 750ti oc lp - stock clocks ...

seems stable enough ...

https://www.westhash.com/index.jsp?p=miners&a=12&d=1&addr=15umzHXF8NzXA4FywmeFbrDHgL8WcPs3wx ( thats our general / common btc address ) ...

#crysx

[sp_]

The hashrates fluxate but it seems to be doing bether than 11MHASH on the pool so far. 12-15MHASH

the -g parameter and the latest optimalizations seems to give 20-30% more quark (verifed on the pool). Let's run it for a while and check stabilty

[sp_]

Remember to send some bits to:

KlausT @github:
  BTC 1H2BHSyuwLP9vqt2p3bK9G3mDJsAi7qChw
  DRK XcM9FXrvZS275pGyGmfJmS98tHPZ1rjErM

Since he helped to fix the broken hash.

[chrysophylax]

The hashrates fluxate but it seems to be doing bether than 11MHASH on the pool so far. 12-15MHASH

the -g parameter and the latest optimalizations seems to give 20-30% more quark (verifed on the pool). Let's run it for a while and check stabilty

it does look that way - yes ...

if there is more optimization that can still be done - we will compile as soon as we possibly can and test ...

there will be a weekend where the whole farm will be pointed to both your btc addresses and mining for you both - as we usually do to donate ...

quark will be the algo - since that is the one you are working on at the moment and its probably one of the most 'profitable' ...

i think ill go to the office tonight and reset the router - its probably the issue here - so that we can continue testing ...

tanx sp ...

#crysx

[fenomenhaa]

Remember to send some bits to:

KlausT @github:
  BTC 1H2BHSyuwLP9vqt2p3bK9G3mDJsAi7qChw
  DRK XcM9FXrvZS275pGyGmfJmS98tHPZ1rjErM

Since he helped to fix the broken hash.

will wait your new relase ))). İ'm so lazy to rebuilt source code ))) .Thanks for your sharing and for your work Sp ))

[sp_]

if there is more optimization that can still be done - we will compile as soon as we possibly can and test ...
there will be a weekend where the whole farm will be pointed to both your btc addresses and mining for you both - as we usually do to donate ...
quark will be the algo - since that is the one you are working on at the moment and its probably one of the most 'profitable' ...
i think ill go to the office tonight and reset the router - its probably the issue here - so that we can continue testing ...
tanx sp ...
#crysx

Thanks

There is more coming. First up is to fix the hash with the -g parameter in other algos, like skein, whirlpoolx, blake, qubit etc..

Hopefully 20-30% gain in the hashrate all over the place.

Go get those bitcoins guys

Happy hashing:)

[chrysophylax]

if there is more optimization that can still be done - we will compile as soon as we possibly can and test ...
there will be a weekend where the whole farm will be pointed to both your btc addresses and mining for you both - as we usually do to donate ...
quark will be the algo - since that is the one you are working on at the moment and its probably one of the most 'profitable' ...
i think ill go to the office tonight and reset the router - its probably the issue here - so that we can continue testing ...
tanx sp ...
#crysx

Thanks

There is more coming. First up is to fix the hash with the -g parameter in other algos, like skein, whirlpoolx, blake, qubit etc..

Hopefully 20-30% gain in the hashrate all over the place.

Go get those bitcoins guys

Happy hashing:)

all good ...

i know this is probably just me thats continues to ask this ... but if there is more x11 optimization and speed to be had - we would be VERY appreciative of it ...

tanx again sp ...

#crysx

[sp_]

The most obvious next step is the --gpu-memclock and --gpu-memspeed parameter..

Commandline overclocking.

When I started to optimize this, my target is 100% faster x11 on the 750ti. I still think it is possible.

5-6MHASH x11 on the 750ti.

[chrysophylax]

The most obvious next step is the --gpu-memclock and --gpu-memspeed parameter..

Commandline overclocking.

When I started to optimize this, my target is 100% faster x11 on the 750ti. I still think it is possible.

5-6MHASH x11 on the 750ti.

that would be awesome ...

if that can be possible - and you have it all functional ... it will be just a matter of time and a weekend for a donation mining spree for you as a tanx for all your effort ...

it actually sounds too good to be true ...

...

#crysx

[sp_]

(...)
it actually sounds too good to be true ...
...
#crysx

Probobly is. Let's enjoy the -g parameter and see what we can do with that.

The titan-x with 12gig ram might do good with settings like -i 28 -g 16

With default settings it does this: (980 reference non overclock)

http://cryptomining-blog.com/4639-nvidia-geforce-gtx-980-vs-gtx-titan-x-mining-performance/




Blake is slow on NVIDIA..

6.4GH/s - 6.9GH/s on a AMD Radeon R9 295X2
3.3GH/s - 3.5GH/s on a AMD Radeon R9 290X
2.9GH/s - 3.1GH/s on a AMD Radeon R9 290
2.6GH/s - 2.8GH/s on a AMD Radeon R9 280X
2.2GH/s - 2.4GH/s on a AMD Radeon R9 280
1.2GH/s - 1.5GH/s on a AMD Radeon R9 270
4.8GH/s - 5.1GH/s on a AMD ATI Radeon 7990
2.2GH/s - 2.8GH/s on a AMD ATI Radeon 7970
2.1GH/s - 2.4GH/s on a AMD ATI Radeon 7950
2.6GH/s - 2.9GH/s on a AMD ATI Radeon 6990
1.4GH/s - 1.5GH/s on a AMD ATI Radeon 6970
1.4GH/s on a AMD ATI Radeon 6950
900MH/s on a AMD ATI Radeon 6870
800MH/s on a AMD ATI Radeon 6850
1.3GH/s on a AMD ATI Radeon 5870
1.1GH/s on a AMD ATI Radeon 5850
1.6GH/s on a ZTEX USB-FPGA 1.15y Quad Spartan-6 LX150 Development Board
1.5GH/s on a Enterpoint Cairnsmore 1 Quad Spartan-6 LX150 Development Board
960MH/s on a Lancelot Dual Spartan-6 LX150 Development Board
360MH/s on a ZTEX USB-FPGA 1.15x Spartan-6 LX150 Development Board

ref:

https://bitcointalk.org/index.php?topic=306894.0

[mendoza1468]

Wow a big thanks for the hard works,
Is there a gentlemen who can post the compile version so we can try !!
Thanks to sp and all other who works for the community   

[sp_]

I will build release 46 later tonight.

[AliMan]

SP, before you build 46. I tested and built the recent update and am getting really low values on quark, as I've only tested that with different -i values.

[arpika]

With the latest build hashrate is really high according to ccminer. (quark algo, yaamp, linux, 970/750ti rig, 50 and 52 capability)
Yaamp reports similar hashrate first but for a longer period the hashrate is lower compared to the eg. 43 version.
Hashrate reported by yaamp is lower even without -g parameter but with -g the difference is more significant. I tried with -g 3, -g 4, without intensity setting and with -i 22, I increased difficulty but the result was same.

[scryptr]

COMMIT 729--

I cloned git on my two rigs, compiled, and began mining Quark about 4 hours ago.  The 6x750ti FTW rig continues to report 50-60Mh/s, and the 2x970 FTW+ rig reports 38-42Mh/s.  The acceptance rates are about 98% for the 750ti rig, and 97% for the 970 rig.  There are very few errors.  Long streams of card hash rates are interspersed with accepted hash (yay!!!) messages.  However, the pool reports slightly lower hash levels total.

Prior to the test of build 729, I was mining with build 724, single-threaded, with the intensities that I reported yesterday.  Currently, the high intensity setting, single threaded, is resulting in better hash reported poolside.  Mining with "-g 4", my machines report 90Mh/s+ total hash rate, the pool reports about 70-75Mh/s.  Mining single-threaded, my machines report 75-80Mh/s, the pool reports about 75Mh/s, sometimes less.

With 4 threads, the high hash rate accepts (yay!!!) messages are less frequent, a large amount of thread rate data is displayed between accepts.  The 750ti thread rate values range between 6-12Mh/s.  The 970 thread rate data ranges between 11-40Mh/s.      

The configuration string for the 2x970 FTW+ rig included "-g 4 -i 23" for performance.  The configuration string for the 6x750ti FTW rig included "-g 4 -i 22" for performance.  These were the highest working intensity values that I could quickly find for either rig.

 --scryptr

[sp_]

SP, before you build 46. I tested and built the recent update and am getting really low values on quark, as I've only tested that with different -i values.

Yes, with one thread the latest quark has dropped 1mhash. I am fixing it now.