Topic: CCminer(SP-MOD) Modded NVIDIA Maxwell / Pascal kernels. - page 729. (Read 2347659 times)
What is blake2s please? Thx
Also, anyone use Mining Rig Rentals for Ethereum? I've tried to get it working a few times, but Stratum is only compatible with a couple miners and not eth-proxy. Getwork seems to always give me a saw tooth pattern as there seems to be connectivity issues of some kind between the MMR and pools.
I'll check out 64bit decred later today. I swear it works fine before, but now getting the weird hashrate decrease I thought was fixed.
I get patterns like that when the difficulty ajustments from the source are to high bensam1231.I'll check out 64bit decred later today. I swear it works fine before, but now getting the weird hashrate decrease I thought was fixed.
I agree, but Ethereum you can't choose difficulty. Pools are set unless you do stratum and MMR doesn't work with that. I definitely see some people with rigs with perfectly fine looking graphs so I don't know what I'm doing wrong.
The 980ti is doing 13mhash @1280 core on the 980ti with my private kernal. $5.4 a day with the current prices. Still profitable with the gpu.
your post is confusing, 5.4 a day with a 980ti mean 2.7 with a 970, which is not that good comapred to 5-6 with etheruem an other algo and btw on what coin, dash?
The 980ti is doing 13mhash @1280 core on the 980ti with my private kernal. $5.4 a day with the current prices. Still profitable with the gpu.
x11 going crazy on nicehash )) forget 'bout decred ))
x11 is asic shit, no tnx
x11 going crazy on nicehash )) forget 'bout decred ))
1. Use intensity -i 30 on compute 5.2 devices(the default is -i 31
2. Don't minemwith difficulty less than 1
In then next version I will reduce the cpu usage.
2. Don't minemwith difficulty less than 1
In then next version I will reduce the cpu usage.
Tried a couple different difficulties on MNpool, doesn't seem to make a difference. It always show up at about 75% of hash, a bit more with the CPU version of decred. I don't have super anemic rigs, they're running on quad cores. Even the CPU version doesn't always use 100% of my processor either. I'm pretty sure it's not because my processor is lacking, especially if it works properly on yiimp.
I can teach you why the kernal is displaying low numbers for low difficulty shares. (and for single cards with a low hashrate)
Take a look at at
https://github.com/tpruvot/ccminer/blob/windows/Algo256/decred.cu
and line 259
if (h[7] == 0 && cuda_swab32(h[6]) <= highTarget) {
We don't care about the 4 first bytes of the hash and assume they are 0. This is to spead up the search.
Here is a found decred block:(hash)
0000000000000d1ec551b6e0b734dbfa31e95059aa84e50f7db2ab244499c87c
0000000 000000d1ec551b6e0b734dbfa31e95059aa84e50f7db2ab244499c87c
but when a pool asks for a low difficulty share
f.eks find a number that is less than this:
00000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff ffffffffffffffffffffffffffff
We are not submitting the shares that have anything else than 00 in the low byte of the first 32 bits. (why should we when we know that the solution doesn't give a block)
If I mod the kernal to search the top 32bits only (h[7]) <= Target the mining software will work exellent at low difficulty, but not so good on higher diff.. We are searching for blocks with 14 leading zero's So I believe the current kernal is good, and the pools are fucked..
Take a look at at
https://github.com/tpruvot/ccminer/blob/windows/Algo256/decred.cu
and line 259
if (h[7] == 0 && cuda_swab32(h[6]) <= highTarget) {
We don't care about the 4 first bytes of the hash and assume they are 0. This is to spead up the search.
Here is a found decred block:(hash)
0000000000000d1ec551b6e0b734dbfa31e95059aa84e50f7db2ab244499c87c
0000000 000000d1ec551b6e0b734dbfa31e95059aa84e50f7db2ab244499c87c
but when a pool asks for a low difficulty share
f.eks find a number that is less than this:
00000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff ffffffffffffffffffffffffffff
We are not submitting the shares that have anything else than 00 in the low byte of the first 32 bits. (why should we when we know that the solution doesn't give a block)
If I mod the kernal to search the top 32bits only (h[7]) <= Target the mining software will work exellent at low difficulty, but not so good on higher diff.. We are searching for blocks with 14 leading zero's So I believe the current kernal is good, and the pools are fucked..
Why should we when we know it doesn't give a block? BECAUSE POOLS WORK THAT WAY, DUDE. Not submitting those is literally burning cash. The problem isn't the pools, it's you.
This would explain why I often have 3-8 consecutive submits without a Yes! I found no solutions that met this preset minimum, it wasn't that I didn't do the work. (single 750TI setup, for now)
I had some miner/pool diference @ suprnova ( 1.7.3 miner) too, and now it behaves much better with Decred#4(64) but with lowered intensity (30 ). Also it is more stable and around 20% more hash. That is for hash displayed. Though coins mined are usually less than predicted what I understand as pool luck.
hashrates fluctates. You need to do a 24hours average to get the real speed.
yea I know just saying its all over the place right now.
hashrates fluctates. You need to do a 24hours average to get the real speed.
and now: 
Summary Miners Shares Hashrate* Reject*
decred 2 0.2447% 1.9 gh/s
Details Extra Algo Diff ES** Hashrate* Reject*
ccminer/1.7.3 d=2 decred 2 674.4 mh/s
ccminer/1.7.3 d=4 decred 4 1.2 gh/s
mahahaha
then this:
Summary Miners Shares Hashrate* Reject*
decred 2 0.2567% 791.6 mh/s
Details Extra Algo Diff ES** Hashrate* Reject*
ccminer/1.7.3 d=2 decred 2 322.5 mh/s
ccminer/1.7.3 d=4 decred 4 469.1 mh/s
Summary Miners Shares Hashrate* Reject*
decred 2 0.2447% 1.9 gh/s
Details Extra Algo Diff ES** Hashrate* Reject*
ccminer/1.7.3 d=2 decred 2 674.4 mh/s
ccminer/1.7.3 d=4 decred 4 1.2 gh/s
mahahaha
then this:
Summary Miners Shares Hashrate* Reject*
decred 2 0.2567% 791.6 mh/s
Details Extra Algo Diff ES** Hashrate* Reject*
ccminer/1.7.3 d=2 decred 2 322.5 mh/s
ccminer/1.7.3 d=4 decred 4 469.1 mh/s
Why should we when we know it doesn't give a block? BECAUSE POOLS WORK THAT WAY, DUDE. Not submitting those is literally burning cash. The problem isn't the pools, it's you.
But this is only a problem for single card rigs with a low starting diff. Yimp has solved it. It starts on diff=1.
But I will fix it in release #5
I will use 2 kernals. if the first 32 bits of the target is 0, run the fastest kernal. If they are not, run the kernal that case on the first bits. (and probobly disable the cpu verification)
I can teach you why the kernal is displaying low numbers for low difficulty shares. (and for single cards with a low hashrate)
Take a look at at
https://github.com/tpruvot/ccminer/blob/windows/Algo256/decred.cu
and line 259
if (h[7] == 0 && cuda_swab32(h[6]) <= highTarget) {
We don't care about the 4 first bytes of the hash and assume they are 0. This is to spead up the search.
Here is a found decred block:(hash)
0000000000000d1ec551b6e0b734dbfa31e95059aa84e50f7db2ab244499c87c
0000000 000000d1ec551b6e0b734dbfa31e95059aa84e50f7db2ab244499c87c
but when a pool asks for a low difficulty share
f.eks find a number that is less than this:
00000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff ffffffffffffffffffffffffffff
We are not submitting the shares that have anything else than 00000000 in the first 32 bits of the hash (why should we when we know that the solution doesn't give a block)
If I mod the kernal to search the top 32bits only (h[7]) <= Target the mining software will work exellent at low difficulty, but not so good on higher diff.. We are searching for blocks with 14 leading zero's So I believe the current kernal is good, and the pools are fucked..
Take a look at at
https://github.com/tpruvot/ccminer/blob/windows/Algo256/decred.cu
and line 259
if (h[7] == 0 && cuda_swab32(h[6]) <= highTarget) {
We don't care about the 4 first bytes of the hash and assume they are 0. This is to spead up the search.
Here is a found decred block:(hash)
0000000000000d1ec551b6e0b734dbfa31e95059aa84e50f7db2ab244499c87c
0000000 000000d1ec551b6e0b734dbfa31e95059aa84e50f7db2ab244499c87c
but when a pool asks for a low difficulty share
f.eks find a number that is less than this:
00000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff ffffffffffffffffffffffffffff
We are not submitting the shares that have anything else than 00000000 in the first 32 bits of the hash (why should we when we know that the solution doesn't give a block)
If I mod the kernal to search the top 32bits only (h[7]) <= Target the mining software will work exellent at low difficulty, but not so good on higher diff.. We are searching for blocks with 14 leading zero's So I believe the current kernal is good, and the pools are fucked..
This thread has become a Pool school. 
Don't hate the miner, hate the mine.
but it even starts to fall off fairly quickly even with 4Don't hate the miner, hate the mine.
ccminer/1.7.3 d=4 decred 4 703.7 mh/s
I had tried many different -diff in my earlier testing, maybe it has changed some to the better now as time has gone by.
That or I just didn't leave it on the higher -diff long enough in my earlier testing.. thanks for the tip.
still at any rate better than what I was seeing..
Miners: 18tvS3deKZK5q4eTtPRWYeEMWmGmuErHgz
Summary Miners Shares Hashrate* Reject*
decred 2 0.1685% 1.4 gh/s
Details Extra Algo Diff ES** Hashrate* Reject*
ccminer/1.7.3 d=2 decred 2 557.1 mh/s
ccminer/1.7.3 d=4 decred 4 879.6 mh/s
Details Extra Algo Diff ES** Hashrate* Reject*
ccminer/1.7.3 d=4 decred 4 938.2 mh/s
ccminer/1.7.3 d=4 decred 4 410.5 mh/s
[2016-03-19 15:23:08] GPU #1: EVGA GTX 750 Ti, 518.42 MH/s
[2016-03-19 15:23:09] accepted: 8/8 (100.00%), 518.47 MH/s yes!
[2016-03-19 15:23:17] GPU #1: EVGA GTX 750 Ti, 518.58 MH/s
ccminer/1.7.3 d=4 decred 4 938.2 mh/s
ccminer/1.7.3 d=4 decred 4 410.5 mh/s
[2016-03-19 15:23:08] GPU #1: EVGA GTX 750 Ti, 518.42 MH/s
[2016-03-19 15:23:09] accepted: 8/8 (100.00%), 518.47 MH/s yes!
[2016-03-19 15:23:17] GPU #1: EVGA GTX 750 Ti, 518.58 MH/s
The pool support Vardiff. and will reduce the diff for the 750ti to 1-2, wich will give bether results over time. the problem is difficulties under 1.
This thread has become a Pool school.
Don't hate the miner, hate the mine.
Don't hate the miner, hate the mine.
Some pool owners are searching for weaknesses in the mining software to cheat you. My modded decred works best for high difficulty, but I can make a version that is excellent on low difficulty as well. Then you will get great stats at suprnova, and bad stats at yiimp.
no parameter used:[2016-03-19 15:09:33] Starting on stratum+tcp://mine.zpool.ca:5744
[2016-03-19 15:09:33] NVML GPU monitoring enabled.
[2016-03-19 15:09:33] 1 miner thread started, using 'decred' algorithm
[2016-03-19 15:09:33] Stratum difficulty set to 0.5
[2016-03-19 15:09:33] mine.zpool.ca:5744 decred block 11855
[2016-03-19 15:09:36] GPU #1: EVGA GTX 750 Ti, 480.65 MH/s
[2016-03-19 15:09:44] GPU #1: EVGA GTX 750 Ti, 518.90 MH/s
[2016-03-19 15:09:48] GPU #1: EVGA GTX 750 Ti, 518.85 MH/s
[2016-03-19 15:09:48] accepted: 1/1 (100.00%), 506.13 MH/s yes!
ccminer/1.7.3 x decred 0.5 205.2 mh/s
exactly. you need d=1 or d=2 or up to get the correct results on the pool. But the miner is displaying the correct results. So you are contributing with 518MHASH and get payed for 200MHASH
ccminer/1.7.3 d=4 decred 4 879.6 mh/s
[2016-03-19 15:06:49] 1 miner thread started, using 'decred' algori
[2016-03-19 15:06:49] Stratum difficulty set to 4
[2016-03-19 15:06:49] mine.zpool.ca:5744 decred block 11854
[2016-03-19 15:06:51] GPU #0: EVGA GTX 960, 776.79 MH/s
[2016-03-19 15:06:56] GPU #0: EVGA GTX 960, 887.19 MH/s
[2016-03-19 15:07:01] GPU #0: EVGA GTX 960, 887.00 MH/s
[2016-03-19 15:07:01] mine.zpool.ca:5744 decred block 11855
[2016-03-19 15:07:05] GPU #0: EVGA GTX 960, 885.90 MH/s
[2016-03-19 15:07:10] GPU #0: EVGA GTX 960, 887.56 MH/s
[2016-03-19 15:07:15] GPU #0: EVGA GTX 960, 887.37 MH/s
[2016-03-19 15:07:20] GPU #0: EVGA GTX 960, 887.19 MH/s
[2016-03-19 15:07:25] GPU #0: EVGA GTX 960, 884.61 MH/s
[2016-03-19 15:07:26] GPU #0: EVGA GTX 960, 883.54 MH/s
[2016-03-19 15:07:26] accepted: 1/1 (100.00%), 874.13 MH/s yes!
[2016-03-19 15:07:27] GPU #0: EVGA GTX 960, 885.55 MH/s
[2016-03-19 15:07:27] accepted: 2/2 (100.00%), 875.27 MH/s yes!
[2016-03-19 15:07:29] GPU #0: EVGA GTX 960, 887.16 MH/s
[2016-03-19 15:07:29] accepted: 3/3 (100.00%), 876.35 MH/s yes!
Miners: 18tvS3deKZK5q4eTtPRWYeEMWmGmuErHgz
Summary Miners Shares Hashrate* Reject*
decred 2 0.0847% 1.3 gh/s
Details Extra Algo Diff ES** Hashrate* Reject*
ccminer/1.7.3 d=4 decred 4 938.2 mh/s
ccminer/1.7.3 d=4 decred 4 410.5 mh/s
[2016-03-19 15:23:08] GPU #1: EVGA GTX 750 Ti, 518.42 MH/s
[2016-03-19 15:23:09] accepted: 8/8 (100.00%), 518.47 MH/s yes!
[2016-03-19 15:23:17] GPU #1: EVGA GTX 750 Ti, 518.58 MH/s
Jump to: