CCminer(SP-MOD) Modded GPU kernels.

[Epsylon3]

-g is useless and will make your fork buggy...

you just have to use -d0,0 to run 2 threads on the same gpu... beware to the cudaDeviceReset() in this case...

[1714904853]

1714904853

[1714904853]

1714904853

[1714904853]

1714904853

[sp_]

With -d 0,0 you get hashrate statistics per thread and not per gpu, also I think my fork need to add some threadsyncronization calls and changed gpuconfig(more sharedmem/less level1cache) to avoid invalid hashes.

I want the -g option like in sgminer, but the current implementation (beta) is not working 100%. Tests have shown that 2 threads can boost performance up to 25% on the highend cards. 960/970/980. on most algorithms.

[arpika]

Some tests...

A test machine with one 970 and one 750ti, Ubuntu 14.04, ccminer 45, quark algo, compiled with both 50/52 capability
default config (without -d and -g parameters): no performance increase and validate errors
-d 0 -g 2 (only 970 runs): 35% performance increase, no errors
-d 1 -g 2 (only 750ti runs): no performance increase and validate errors

[sp_]

Some tests...
A test machine with one 970 and one 750ti, Ubuntu 14.04, ccminer 45, quark algo, compiled with both 50/52 capability
default config (without -d and -g parameters): no performance increase and validate errors
-d 0 -g 2 (only 970 runs): 35% performance increase, no errors
-d 1 -g 2 (only 750ti runs): no performance increase and validate errors

The problem is that the 750ti is out of resources.

I will fix it so that it will give a boost and no validation errors on all the maxwell cards. I just need to reduce the constmem/sharedmem usage and reduce threads per block for the kernals.

I think I will recode the -g parameter to support the -d parameter.

just give me some more time. This will be the biggest boost in hashrates in months..

For a 35% boost I think it is time to include a small developer fee of 2%. What do you think guys?

I will keep the sourcecode opensource and linux compatible.

[ol92]

Some tests...
A test machine with one 970 and one 750ti, Ubuntu 14.04, ccminer 45, quark algo, compiled with both 50/52 capability
default config (without -d and -g parameters): no performance increase and validate errors
-d 0 -g 2 (only 970 runs): 35% performance increase, no errors
-d 1 -g 2 (only 750ti runs): no performance increase and validate errors

The problem is that the 750ti is out of resources.

I will fix it so that it will give a boost and no validation errors on all the maxwell cards. I just need to reduce the constmem/sharedmem usage and reduce threads per block for the kernals.

I think I will recode the -g parameter to support the -d parameter.

just give me some more time. This will be the biggest boost in hashrates in months..

For a 35% boost I think it is time to include a small developer fee of 2%. What do you think guys?

I will keep the sourcecode opensource and linux compatible.

I agree with the developper fee.
This is more fair than a fixed amount for small miners ...
You can made it switchable in the source code and force it in the binary releases (I am using the binary releases and I will be happy to contribute for 2% for your work.)

[pallas]

how are you going to implement the developer fee? time based pool switch?

[antonio8]

The -d 0 -g 2 does not work. It is piggy backing a second card.

Stop all your cards and then run the bat. Look at Precision or Afterburner and you will see two cards are actually running. Device 0 and some other random card. I even tried -d 0 -g 3 and I had 3 cards running. So the increase in hash is actually coming from other cards running along with device 0. I do not thing this is how it works for cgminer/sgminer.

[totoy]

The -d 0 -g 2 does not work. It is piggy backing a second card.

Stop all your cards and then run the bat. Look at Precision or Afterburner and you will see two cards are actually running. Device 0 and some other random card. I even tried -d 0 -g 3 and I had 3 cards running. So the increase in hash is actually coming from other cards running along with device 0. I do not thing this is how it works for cgminer/sgminer.

agreed. I tried using -d 0 -g 2 and two cards are running.

[sp_]

1. disable the 750ti cards in device manager. (only works on 960,970,980)
2. The head@git is broken. use release 45 exe file and run x11 with -g 4 -i 10. or other settings (no more than 4 cards)

Meassure the hashrate on a pool over time.

The g parameter is not compatible with the -d switch, but I will fix it.

Not very stable with invalid hashes(the invalid hashes will not be submitted to the pool), but you should get higher average rates.

[scryptr]

CUDAMINER--

When I began mining Scrypt with CudaMiner, I picked up the trick of mining with two instances of the miner running simultaneously.  The results were a slightly improved total hash rate.  Also, if one instance of the miner crashed, the other would pick up the slack until I could set things right.

The "gputhreads" option is promising.  However, I tried the "-d 0,0,1,1,2,2,3,3,4,4,5,5" switch in CCminer v45 and it apparently does start two threads per gpu.  Mining Quark, I receive "does not validate on CPU" errors, but also have a higher hash rate and 99%+ acceptance rate on my 6x750ti FTW rig.  The hash rate is currently 36.8Mh/s for the rig.

My GTX 960 SSC gets about 9.5Mh/s with "-d 0,0".  The threads run about 1/2 the total hash rate with greater variance than a single thread.  You can tell the threads are running concurrently.  The performance with the "-d" switch appears more stable than when using the "-g" switch currently.

If the "gputhreads" switch is de-bugged, and allows for better control of the miner, I am all for it.         --scryptr


750ti FTW Rig


960 SSC Card

[5w00p]

CUDAMINER--

When I began mining scrypt with CudaMiner, I picked up the trick of mining with two instances of the miner running simultaneously.  The results were a slightly improved total hash rate.  Also, if one instance of the miner crashed, the other would pick up the slack until I could set things right.

The "gputhreads" option is promising.  However, I tried the "-d 0,0,1,1,2,2,3,3,4,4,5,5" switch and it apparently does start two threads per gpu.  I receive "does not validate on CPU" errors, but also have a higher hash rate and 99%+ acceptance rate on my 6x750ti FTW rig.  The hash rate is currently 36.8Mh/s for the rig.

My GTX 960 SSC gets about 9.5Mh/s with "-d 0,0".  The threads run about 1/2 the total hash rate with greater variance than a single thread.  You can tell the threads are running concurrently.  The performance with the "-d" switch appears more stable than when using the "-g" switch currently.

If the "gputhreads" switch is de-bugged, and allows for better control of the miner, I am all for it.         --scryptr

images snipped

Cool.

What algorithm? Scrypt?

[scryptr]

CUDAMINER--

When I began mining Scrypt with CudaMiner, I picked up the trick of mining with two instances of the miner running simultaneously.  The results were a slightly improved total hash rate.  Also, if one instance of the miner crashed, the other would pick up the slack until I could set things right.

The "gputhreads" option is promising.  However, I tried the "-d 0,0,1,1,2,2,3,3,4,4,5,5" switch in CCminer v45 and it apparently does start two threads per gpu.  Mining Quark, I receive "does not validate on CPU" errors, but also have a higher hash rate and 99%+ acceptance rate on my 6x750ti FTW rig.  The hash rate is currently 36.8Mh/s for the rig.

My GTX 960 SSC gets about 9.5Mh/s with "-d 0,0".  The threads run about 1/2 the total hash rate with greater variance than a single thread.  You can tell the threads are running concurrently.  The performance with the "-d" switch appears more stable than when using the "-g" switch currently.

If the "gputhreads" switch is de-bugged, and allows for better control of the miner, I am all for it.         --scryptr

images snipped

Cool.

What algorithm? Scrypt?

I began mining Scrypt with CudaMiner.  The images are of a single instance (per machine) of CCminer mining Quark.  The algo being mined is output to the screen in blue.        --scryptr       (P.S.  I edited for clarity)

[scryptr]

SPLIT THREADS ERROR-

I just captured this:


750ti FTW Rig with error

The anomalous "GPU #11" represents one of the threads, but generally the output only displays GPUs #0-5.  As you can see, the acceptance rate while mining Quark with v45 is still good.       --scryptr

[rednoW]

The anomalous "GPU #11" represents one of the threads, but generally the output only displays GPUs #0-5.  As you can see, the acceptance rate, while mining Quark with v45, is still good.       --scryptr

did the pool confirm the numbers that miner shows? I mean hashrate ...
I tried with my single card with -d 0,0 option and it gives (sometimes but rather often) 'does not validate on CPU' for non-existing GPU1.
Also higher hashrate the miner shows is not confirmed by the pool.

[scryptr]

The anomalous "GPU #11" represents one of the threads, but generally the output only displays GPUs #0-5.  As you can see, the acceptance rate while mining Quark with v45 is still good.       --scryptr

did the pool confirm the numbers that miner shows? I mean hashrate ...
I tried with my single card with -d 0,0 option and it gives 'does not validate on CPU' for non-existing GPU1.
Also higher hashrate the miner shows is not confirmed by the pool.

The pool rates fluctuate between 30-40Mh/s.  I never know when they are accurate.  It is like an "ebb and flow" phenomenon to me.

If you have ever done any CPU mining, multiple threads can be used with the "--threads 16" command.  If you use that on an i7, you'll get 2 threads per virtual CPU on the Quad-Core.       --scryptr

[rednoW]

The only reason I see for running more threads then physical C(G)PUs is to fill the gaps between tasks. You can easily see that gaps on GPU-Z load graph. In other cases it is useless I think. There is a case in some memory intensive applications when running multiple threads on single CPU gives boost over single thread. But this is a case when single-threaded app is bad coded not fitting data in cache.

[rednoW]

Code:

[2015-04-21 20:23:02] GPU #0: GeForce GTX 750, 4110 kH/s
[2015-04-21 20:23:02] GPU #0: GeForce GTX 750, 555.39 kH/s
[2015-04-21 20:23:03] yaamp.com:4733 qubit block 485
[2015-04-21 20:23:03] GPU #0: GeForce GTX 750, 4178 kH/s
[2015-04-21 20:23:03] GPU #0: GeForce GTX 750, 357.77 kH/s
[2015-04-21 20:23:07] GPU #0: GeForce GTX 750, 4145 kH/s
[2015-04-21 20:23:07] accepted: 13/13 (100.00%), 5792 khash/s yay!!!
[2015-04-21 20:23:08] yaamp.com:4733 qubit block 486
[2015-04-21 20:23:08] GPU #0: GeForce GTX 750, 404.75 kH/s
[2015-04-21 20:23:08] GPU #0: GeForce GTX 750, 4067 kH/s
[2015-04-21 20:23:12] GPU #0: GeForce GTX 750, 4105 kH/s
[2015-04-21 20:23:12] accepted: 14/14 (100.00%), 5799 khash/s yay!!!
[2015-04-21 20:23:22] GPU #0: GeForce GTX 750, 4120 kH/s
[2015-04-21 20:23:23] accepted: 15/15 (100.00%), 5802 khash/s yay!!!
[2015-04-21 20:23:25] GPU #0: GeForce GTX 750, 4114 kH/s
[2015-04-21 20:23:25] accepted: 16/16 (100.00%), 5801 khash/s yay!!!
[2015-04-21 20:23:27] yaamp.com:4733 qubit block 486
[2015-04-21 20:23:27] GPU #0: GeForce GTX 750, 679.92 kH/s
[2015-04-21 20:23:27] GPU #0: GeForce GTX 750, 4084 kH/s
[2015-04-21 20:23:34] yaamp.com:4733 qubit block 487
[2015-04-21 20:23:34] GPU #0: GeForce GTX 750, 4114 kH/s
[2015-04-21 20:23:34] GPU #0: GeForce GTX 750, 417.11 kH/s
[2015-04-21 20:23:38] GPU #0: GeForce GTX 750, 4142 kH/s
[2015-04-21 20:23:39] accepted: 17/17 (100.00%), 5806 khash/s yay!!!

this is qubit on my single gtx750 with release 45
ccminer.exe --cpu-priority 5 -d 0,0 -i 16 -a qubit

But I'm not sure that this numbers are real performance ...

[scryptr]

The only reason I see for running more threads then physical C(G)PUs is to fill the gaps between tasks. You can easily see that gaps on GPU-Z load graph. In other cases it is useless I think. There is a case in some memory intensive applications when running multiple threads on single CPU gives boost over single thread. But this is a case when single-threaded app is bad coded not fitting data in cache.

HASH RATE --

I always get a little more hash.  It only takes a command line switch, no real effort.  The real trick is tuning the code to make good use of it.

I am now mining Quark at close to 37Mh/s on my 750ti FTW rig, and that is 400kh/s better than yesterday with the same v45 code. My 960 SSC is getting up to 10Mh/s now:


960 SSC nearing max performance mining Quark, v45 sp_hash

The hash rate fluctuates.       --scryptr

[sp_]

I have submitted fixes to the -g parameter. It now supports the -d parameter. I have also remove cudadevicereset, and corrected the stats. (total sum for each gpu)

So

ccminer -d 1,2 -g 2

is the same as

ccminer -d 1,1,2,2

but the stats will give the total hash of the each gpu

[DougB62]

Question - I have been building right along with VS Express 2013, but now I get this?

Code:

Error	3	error MSB3721: The command ""C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v6.5\bin\nvcc.exe" -gencode=arch=compute_20,code=\"sm_21,compute_20\" -gencode=arch=compute_30,code=\"sm_30,compute_30\" -gencode=arch=compute_35,code=\"sm_35,compute_35\" -gencode=arch=compute_50,code=\"sm_50,compute_50\" -gencode=arch=compute_52,code=\"sm_52,compute_52\" --use-local-env --cl-version 2013 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin"  -I. -Icompat -I"compat\curl-for-windows\curl\include" -Icompat\jansson -Icompat\getopt -Icompat\pthreads -I"compat\curl-for-windows\openssl\openssl\include" -I"compat\curl-for-windows\zlib" -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v6.5\include" -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v6.5\include" -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v6.5\include"    --keep --keep-dir Release -maxrregcount=80 --ptxas-options=-v --machine 32 --compile -cudart static --ptxas-options="-O2"     -DWIN32 -DNDEBUG -D_CONSOLE -D_CRT_SECURE_NO_WARNINGS -DCURL_STATICLIB -DUSE_WRAPNVML -DSCRYPT_KECCAK512 -DSCRYPT_CHACHA -DSCRYPT_CHOOSE_COMPILETIME -D_MBCS -Xcompiler "/EHsc /W3 /nologo /Ox /Zi  /MT  " -o Release\fermi_kernel.cu.obj "C:\Users\Linux\Desktop\ccminer-windows\scrypt\fermi_kernel.cu"" exited with code 1.	C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\BuildCustomizations\CUDA 6.5.targets	593	9	ccminer

Edit - just noticed this, I'm building for maxwell though?: Release\fermi_kernel.cu.obj "C:\Users\Linux\Desktop\ccminer-windows\scrypt\fermi_kernel.cu