sp_ (OP)
Legendary
Offline
Activity: 2912
Merit: 1087
Team Black developer
|
|
April 22, 2015, 11:02:58 AM |
|
-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.
|
|
|
|
AliMan
|
|
April 22, 2015, 11:36:52 AM |
|
I was initially only using -g with the rest, but -i 22 with -g does give some boost.
|
|
|
|
tbearhere
Legendary
Offline
Activity: 3164
Merit: 1003
|
|
April 22, 2015, 11:38:04 AM |
|
-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_ (OP)
Legendary
Offline
Activity: 2912
Merit: 1087
Team Black developer
|
|
April 22, 2015, 11:43:12 AM |
|
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
|
|
April 22, 2015, 11:53:16 AM |
|
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
|
|
April 22, 2015, 12:01:47 PM |
|
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
Legendary
Offline
Activity: 2842
Merit: 1091
--- ChainWorks Industries ---
|
|
April 22, 2015, 12:16:18 PM Last edit: April 22, 2015, 12:31:02 PM by 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_ (OP)
Legendary
Offline
Activity: 2912
Merit: 1087
Team Black developer
|
|
April 22, 2015, 12:35:16 PM |
|
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
Legendary
Offline
Activity: 1582
Merit: 1019
011110000110110101110010
|
|
April 22, 2015, 09:41:12 PM |
|
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
|
Jump you fuckers! | The thing about smart motherfuckers is they sound like crazy motherfuckers to dumb motherfuckers. | My sig space for rent for 0.01 btc per week.
|
|
|
chrysophylax
Legendary
Offline
Activity: 2842
Merit: 1091
--- ChainWorks Industries ---
|
|
April 23, 2015, 12:24:57 AM |
|
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_ (OP)
Legendary
Offline
Activity: 2912
Merit: 1087
Team Black developer
|
|
April 23, 2015, 05:53:59 AM |
|
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
|
|
April 23, 2015, 06:31:58 AM |
|
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
Legendary
Offline
Activity: 2842
Merit: 1091
--- ChainWorks Industries ---
|
|
April 23, 2015, 06:56:12 AM |
|
ok ... so its more of an issue than at first thought ...
will wait till you come out with a fix ...
tanx again ...
#crysx
|
|
|
|
sp_ (OP)
Legendary
Offline
Activity: 2912
Merit: 1087
Team Black developer
|
|
April 23, 2015, 07:05:56 AM |
|
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_ (OP)
Legendary
Offline
Activity: 2912
Merit: 1087
Team Black developer
|
|
April 23, 2015, 12:10:17 PM |
|
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
Legendary
Offline
Activity: 3164
Merit: 1003
|
|
April 23, 2015, 02:06:01 PM |
|
sp when I download ccminer 1.6.2 x86 zip... the folder is empty.
|
|
|
|
mendoza1468
Newbie
Offline
Activity: 54
Merit: 0
|
|
April 23, 2015, 02:53:58 PM |
|
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
Legendary
Offline
Activity: 1796
Merit: 1028
|
|
April 23, 2015, 04:20:58 PM Last edit: April 23, 2015, 06:47:25 PM by 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_ (OP)
Legendary
Offline
Activity: 2912
Merit: 1087
Team Black developer
|
|
April 23, 2015, 05:51:44 PM |
|
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
Legendary
Offline
Activity: 1796
Merit: 1028
|
|
April 23, 2015, 06:46:10 PM Last edit: April 23, 2015, 07:09:20 PM by 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
|
|
|
|
|