Topic: CCminer(SP-MOD) Modded NVIDIA Maxwell / Pascal kernels. - page 1127. (Read 2347601 times)

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

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

tanx again ...

#crysx

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.

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.

tanx sp ...

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

really dont like these time zones :| ...

#crysx

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

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

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

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

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.

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

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

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

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.

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

I compiled that way
You also suggested to lower the priority. I reduced the nice level by 5 (from 0 to +5) but same performance.

Nope, it shows higher hashrate then my favorite Release43 but it doesn't confirm by the pool.

Thanks.

when you build yourself you need to make sure that you have compute5_2  in the makefile. Compute 5.0 will cause invalid hash on compute 5.2 cards for some reason.

nvcc_ARCH  = -gencode=arch=compute_50,code=\"sm_50,compute_50\"
nvcc_ARCH += -gencode=arch=compute_52,code=\"sm_52,compute_52\"

Sent you 0.015 BTC. It's not a lot but a thanks for your work.

https://blockchain.info/tx/da1253e35c58439938496088483aec4838a8aec7ecb2abaa1181555ddca46dfd

Thanks' for your Work!

Ahh i don't know, how to do this ))) .I'm very bad about software, It seems i need cuda kit,ohh it's more then 900mb )).Maybe it's better to wait your release ))) .If i find time,i'll check )))