CCminer(SP-MOD) Modded GPU kernels.

[sp_]

-i 10 -g 4 seems to work with the latest on git.
x11 is 25% faster on my 3 card testrig. gtx970,960,750ti

Do we really need to use these? I just over clock. Or would I get a higher hashrate if I used these and over clocked?  thx

These parameters can be used together with overclocking. Using multiple threads is good because the memory get divided into smaller continious blocks and more
resources on the gpu is being used. This leads to a higher total intensity

-i 22 -g 4 is similar to no g parameter and -i 24 (memory wise)

The -g parameter is currently being tested and developed.
As long as you get "does not validate on the cpu" the hashrate on the pool will be lower than in the miner.
Give me some more days, and I will fix it. (hopefully)

The hashfunctions are working with multiple threads in benchmarkmode.

To get an idea of the speed run ccminer with --benchmark parameter.

This is fixable.

[1714919695]

1714919695

[1714919695]

1714919695

[AliMan]

I was initially only using -g with the rest, but -i 22 with -g does give some boost.

[tbearhere]

-i 10 -g 4 seems to work with the latest on git.
x11 is 25% faster on my 3 card testrig. gtx970,960,750ti

Do we really need to use these? I just over clock. Or would I get a higher hashrate if I used these and over clocked?  thx

These parameters can be used together with overclocking. Using multiple threads is good because the memory get divided into smaller continious blocks and more
resources on the gpu is being used. This leads to a higher total intensity

-i 22 -g 4 is similar to no g parameter and -i 24 (memory wise)

The -g parameter is currently being tested and developed.
As long as you get "does not validate on the cpu" the hashrate on the pool will be lower than in the miner.
Give me some more days, and I will fix it. (hopefully)

The hashfunctions are working with multiple threads in benchmarkmode.

To get an idea of the speed run ccminer with --benchmark parameter.

This is fixable.

Thx  sp ..your doing a great job...keep up the good work. 

[sp_]

I was initially only using -g with the rest, but -i 22 with -g does give some boost.

Yes, it does, even with some validation errors. If you run in benchmark mode, you will see what the hashrate will look like when the bug is fixed. Looks like 25% on the highend cards

[AliMan]

Just tried it on x11, the -i 22 doesn't work on it, the program crashes giving an error on I guess line 647, it worked on quark though.

Edit: So I decreased the i one to -i 21 and it's working on x13 for now, gotta find some i that works for all when using multi algo switch.

[AliMan]

I was initially only using -g with the rest, but -i 22 with -g does give some boost.

Yes, it does, even with some validation errors. If you run in benchmark mode, you will see what the hashrate will look like when the bug is fixed. Looks like 25% on the highend cards

I got a boost of 500-700 kh/s on Quark on my 980 with using the -i 22 on the pool.

[chrysophylax]

Just tried it on x11, the -i 22 doesn't work on it, the program crashes giving an error on I guess line 647, it worked on quark though.

Edit: So I decreased the i one to -i 21 and it's working on x13 for now, gotta find some i that works for all when using multi algo switch.

with x11 on our farm - the -i value is at its peak using 20.6 or more stable at 20.5 - and the -g values of sorts just crash the miner ...

quark -g 3 -i 22 works though with a lot of cpu validation errors and wild values in hashrate ...

we have been running these values for a few hours now - and in comparison to having the old parameters -r 3 -R 10 - is actually showing LESS overall hashrate on the farm than the old parameters were successfully processing at with a much more stable hashrate and share count ...

this can be seen in the 2 day history on westhash as we are still currently running the 'new' settings and latest v45 under quark ... seen here - https://www.westhash.com/index.jsp?p=miners&a=12&d=2&addr=15umzHXF8NzXA4FywmeFbrDHgL8WcPs3wx ...

if we switch back to the old parameters - we get a steady hashrate on the miner and what seems to be a higher hashrate rate on the pool ...

not really too sure if this is due to the wild fluctuations in the miner hashrate or not - but it seems to be that the steady lower MINER hashrate on the old parameters give a higher POOL hashrate with less errors / issues ...

if that all makes sense ... apologies as im very tired ...

sp - any ideas? ...

edit - we will be changing the miners back to the original quark parameters ( -r 3 -R 10 ) to show the comparison between the old and new performances ... which in turn should show a 'dip' in the hashrate of the pool - which in turn again shows a 'dip' in the payouts ( though with westahsh the payouts are non-conclusive as they are fluctuation prone also ) ...

#crysx

[sp_]

There is an error in the hashrate calculation when using the -g parameter


first rollback the last changeset @git and then change

in ccminer.cpp:

   if( opt_n_gputhreads>1)
       {
           int index = thr_id / opt_n_gputhreads;
      gpu = index*opt_n_gputhreads + gpu;
   }

Should be changed to:

   if( opt_n_gputhreads>1)
       {
           int index = thr_id / opt_n_gputhreads;
      gpu = index*opt_n_gputhreads + (gpu%opt_n_gputhreads);
   }

2 places.


I will fix it in some hours@github

[coinits]

CCMINER -g 3 -i 22 --

For me that only does 37.3 per rig and and it's not even fluctuating. Without using -g and with -i 23.6 I get 37.6 per rig of Gigabyte OC cards with +140 on the core.

For some reason I was unable to find any algo which resulted in more hash using -g.  

LATEST MOD --

Did you download and compile the last mod of v45 of the day?  Yesterday's version was giving me the results that you describe.  The pre-compiled Windows version is several days old.  I was not able to build today's mods until the last version posted on git.       --scryptr

I want to make an attempt at compiling.

Couple of questions:

Link to github resource
Are you using Visual Studio? If so what version?
What dependencies do I need?

Thank you

[chrysophylax]

There is an error in the hashrate calculation when using the -g parameter


first rollback the last changeset @git and then change

in ccminer.cpp:

   if( opt_n_gputhreads>1)
       {
           int index = thr_id / opt_n_gputhreads;
      gpu = index*opt_n_gputhreads + gpu;
   }

Should be changed to:

   if( opt_n_gputhreads>1)
       {
           int index = thr_id / opt_n_gputhreads;
      gpu = index*opt_n_gputhreads + (gpu%opt_n_gputhreads);
   }

2 places.


I will fix it in some hours@github

tanx sp ...

ill try that when i get into the office today ...

really dont like these time zones :| ...

#crysx

[sp_]

don't bother. Fixing the stats is not enough. I need to find out why the miner report "does not validate on the cpu" with more than one thread per gpu.

[Schleicher]

don't bother. Fixing the stats is not enough. I need to find out why the miner report "does not validate on the cpu" with more than one thread per gpu.

I think it's possible that the threads get different work sometimes.
Since there is only one array on the gpu for the input, the data gets mixed up between the threads.

[chrysophylax]

ok ... so its more of an issue than at first thought ...

will wait till you come out with a fix ...

tanx again ...

#crysx

[sp_]

don't bother. Fixing the stats is not enough. I need to find out why the miner report "does not validate on the cpu" with more than one thread per gpu.

I think it's possible that the threads get different work sometimes.
Since there is only one array on the gpu for the input, the data gets mixed up between the threads.

Yes, can you help me find the bug? Benchmark mode is working..

[sp_]

I want to make an attempt at compiling.

Couple of questions:

Link to github resource
Are you using Visual Studio? If so what version?
What dependencies do I need?

Thank you

install Cuda 6.5

Visual studio 2013

https://github.com/sp-hash/ccminer

[tbearhere]

sp when I download ccminer 1.6.2 x86  zip... the folder is empty.

[mendoza1468]

Is there a way to repair those problems :
Api bind to port 4068 failed
result for xxxxx does not validate on cpu

Gtx 970 X 2 ccminer 1.5.45
Thanks

[scryptr]

HASH RATE --

I've been mining Quark for the last few days.  This morning I reluctantly removed the gputhreads "-g 3" flag from all of my config files, and restarted my Linux rigs with "-i 23" as the only performance aid.  I now have a 2x970 FTW+ rig and the same 6x750ti FTW rig mining Quark.  My 960 SSC card is in my working computer, running on Win 7 x64.  It is running the last Windows release of v45, compiled and posted by SP_ .  The rigs are running commit 723, compiled from git locally.

RESULTS:

  2x970 FTW+  --  14.8Mh/s per card, 29.8Mh/s for the rig, 99%+ accepts, no "CPU" errors (headless rig, -i 23)
  6x750ti FTW  --  6.35Mh/s per card, 38.1Mh/s for the rig, 98%+ accepts, no "CPU"errors  (headless rig, -i 23.5)
  1x960 SSC  --  9.425Mh/s per card, total, 98%+ accepts, no "CPU" errors (driving a monitor, computer in daily use, -i 20)

My 6x 750ti FTW rig is at least 1.7Mh/s faster than with v44.  These single-threaded rates are reflected poolside with reasonable agreement.  Poolside rates always seem to fluctuate, and have done so as long as I have mined.  I am not getting any "...does not validate on CPU" errors.

I am hoping that SP_ can ferret out the bugs soon.  I am waiting for another intermediate commit before I git and compile again.       --scryptr

[sp_]

I have fixed the errors now in quark.  (github)

-g is now working and not producing any "does not validate on the cpu"

Please test.

I will continue with the other algos

[scryptr]

I have fixed the errors now in quark.  (github)

-g is now working and not producing any "does not validate on the cpu"

Please test.

I will continue with the other algos

VIRTUAL GPUs DON'T COUNT--

I cloned from git and compiled commit #724.  In my two card rig, the only accepts are from the base GPUs (#0 and #1).  Whenever another thread is reported from a higher numbered (virtual) GPU, it is a "CPU" error.  The same is happening in my 6x750ti rig.  Both rigs have the same fluctuating higher/lower hash rates as prior, and a quick check gives slightly lower poolside results than single theaded mining.

Single-threaded results are similar to the last commit, #723.  I might try separate instances mining single-threaded concurrently, the way I used to mine with CudaMiner.  The GPUs could take it, and produced slightly more hash.  And, if one instance crashed, the other would speed up and take its place.  This reminds me of DoubleDOS and DeskMate...

--scryptr