CCminer(SP-MOD) Modded GPU kernels.

[sp_]

5MHASH on the gtx: 750ti
10MHASH on the gtx 970:

sp-mod 64-git

ccminer -q -i 19.2 -g 2 -a lyra2v2  -C (--benchmark)

but there is a bug. The miner will crash after a while when mining on a pool. And use the quiet mode because you get too much information on the ccminer screen without it.

[1714677368]

1714677368

[1714677368]

1714677368

[1714677368]

1714677368

[1714677368]

1714677368

[sp_]

I also submitted a 20% reduction in memory on the lyra2v2 algo so you can have higher intensities than before..

The default for the 750ti is -X 16. in release 63 it was -X 8
The default for the 970 is -X 26, in release 63 it was -X 16

[t-nelson]

sp_,

Is there some way to do "minimal rebuilds" of the CUDA kernels on Windows?

It's pretty lame sitting around for 10min while all that unchanged stuff rebuilds after I change one line.

[Slava_K]

Commit 997 lyra2v2 is slower on sm52 (from 27.9  Mh to 26.7-27.6 Mh) and not stable in miner. sm 50 not tested.
Nicehash pool side show - not more 20Mh. when pool set diff to 8 - miner dont found any hashes. Then diff resetting to 4 and again hashes founded.GPU usage is jumping up and down.
After resetting diff on pool accepted speed is starting from zero. Stratum connection reseted.
PS. 2x980GTX and 960GTX in one rig.

[djm34]

sp_,

Is there some way to do "minimal rebuilds" of the CUDA kernels on Windows?

It's pretty lame sitting around for 10min while all that unchanged stuff rebuilds after I change one line.

I don't think it is possible or you would have to write different files for different kernel. But no matter what you will still need to recompile it (for what it is worth, it is a lot better than opencl)

[djm34]

I also submitted a 20% reduction in memory on the lyra2v2 algo so you can have higher intensities than before..

The default for the 750ti is -X 16. in release 63 it was -X 8
The default for the 970 is -X 26, in release 63 it was -X 16

not entirely a good idea, you are clearly sacrificing the 3.5 compute cards... (already noticed that in some previous change... I understand that you don't have these card, don't understand why you are removing the optimization done here) also it doesn't really matter how much memory you allocate if it isn't used, that's why I used that "#define memshift 3 (or 4")" to do that.
Don't really understand either why you are pushing the intensity so high, at some point it doesn't help anymore and create more bottleneck on mem access...

[djm34]

and a little more  (the 750ti is oc at +200 mem/core, actually core matters more than mem)

Nice, didn't take you too long

I'm thinking we agree on how it should be done, tried that one thing I hadn't had time to try yet

most likely  (however some variations around that are probably possible)

[t-nelson]

sp_,

Is there some way to do "minimal rebuilds" of the CUDA kernels on Windows?

It's pretty lame sitting around for 10min while all that unchanged stuff rebuilds after I change one line.

I don't think it is possible or you would have to write different files for different kernel. But no matter what you will still need to recompile it (for what it is worth, it is a lot better than opencl)

Actually this seems to be working.  I think the commit I reverted touched WAY more than I thought it did is all.

[sp_]

I also submitted a 20% reduction in memory on the lyra2v2 algo so you can have higher intensities than before..
The default for the 750ti is -X 16. in release 63 it was -X 8
The default for the 970 is -X 26, in release 63 it was -X 16

not entirely a good idea, you are clearly sacrificing the 3.5 compute cards... (already noticed that in some previous change... I understand that you don't have these card, don't understand why you are removing the optimization done here) also it doesn't really matter how much memory you allocate if it isn't used, that's why I used that "#define memshift 3 (or 4")" to do that.
Don't really understand either why you are pushing the intensity so high, at some point it doesn't help anymore and create more bottleneck on mem access...

Yes, this is the maxwell mod. Less memory is good on windows because the operating system have problems with allocation big blocks of gpu-mem. Windows 8/10. With -X 16 the 750ti is using 1.8 Gig of memory in lyra2v2 +30 khash.

[Slava_K]

Now testing lira2v2 on sm50 (750Ti).
Miner show good hashrate. On pool side (nicehash) every 2.5 minutes connection reseted (when diff go from 2 up to 4 and 40 seconds miner dont take any yay!!). Problem same.
Pool shows speed 3-6 Mh - my 2x750Ti make 8.4 Mh...

[djm34]

I also submitted a 20% reduction in memory on the lyra2v2 algo so you can have higher intensities than before..
The default for the 750ti is -X 16. in release 63 it was -X 8
The default for the 970 is -X 26, in release 63 it was -X 16

not entirely a good idea, you are clearly sacrificing the 3.5 compute cards... (already noticed that in some previous change... I understand that you don't have these card, don't understand why you are removing the optimization done here) also it doesn't really matter how much memory you allocate if it isn't used, that's why I used that "#define memshift 3 (or 4")" to do that.
Don't really understand either why you are pushing the intensity so high, at some point it doesn't help anymore and create more bottleneck on mem access...

Yes, this is the maxwell mod. Less memory is good on windows because the operating system have problems with allocation big blocks of gpu-mem. Windows 8/10. With -X 16 the 750ti is using 1.8 Gig of memory in lyra2v2 +30 khash.

no actually it doesn't have a problem allocating big-block, as long as it doesn't use it full (checked that with ethereum), I suspect the compiler knows what to really allocate at compile time and actually the memshift of 4 was to allow smoother accesses to global mem at least with the 780ti... (problem was reversed in classic lyra)

[Grim]

release 63 (different codebase) --> solomining works
any other release including 64  --> solomining wont work

[zTheWolfz]

I also submitted a 20% reduction in memory on the lyra2v2 algo so you can have higher intensities than before..
The default for the 750ti is -X 16. in release 63 it was -X 8
The default for the 970 is -X 26, in release 63 it was -X 16

not entirely a good idea, you are clearly sacrificing the 3.5 compute cards... (already noticed that in some previous change... I understand that you don't have these card, don't understand why you are removing the optimization done here) also it doesn't really matter how much memory you allocate if it isn't used, that's why I used that "#define memshift 3 (or 4")" to do that.
Don't really understand either why you are pushing the intensity so high, at some point it doesn't help anymore and create more bottleneck on mem access...

Yes, this is the maxwell mod. Less memory is good on windows because the operating system have problems with allocation big blocks of gpu-mem. Windows 8/10. With -X 16 the 750ti is using 1.8 Gig of memory in lyra2v2 +30 khash.

no actually it doesn't have a problem allocating big-block, as long as it doesn't use it full (checked that with ethereum), I suspect the compiler knows what to really allocate at compile time and actually the memshift of 4 was to allow smoother accesses to global mem at least with the 780ti... (problem was reversed in classic lyra)

Link to your latest release please, thanks.

[sp_]

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

number 64.

But there are some experimenting on github with multiple threads.

[zTheWolfz]

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

number 64.

But there are some experimenting on github with multiple threads.

Sorry my request was to djm34. I had already seen and downloaded your latest release. thanks.

[sp_]

Now testing lira2v2 on sm50 (750Ti).
Miner show good hashrate. On pool side (nicehash) every 2.5 minutes connection reseted (when diff go from 2 up to 4 and 40 seconds miner dont take any yay!!). Problem same.
Pool shows speed 3-6 Mh - my 2x750Ti make 8.4 Mh...

There seems to be a bug if you use the -q (quiet) mode. Don't use -g 2 yet it's not working.

[Grim]

- Regarding developer work -

We should simply have a trusted escrow BTC address where we donate money to for a CERTAIN algo.

Once the dev thinks the escrow is worth grabbing he makes his work/code available as open source.
If it never reaches the threshold the dev thinks it's worth, then the escrow guy will refund the donators.

I would bet that a few btc would come together for each release.



This escrow model should be in BTC !!!
For smaller coins a % fee is utterly devastating to the coin itself cuz one guy (the miner dev) can dump below market price forever.


- EXAMPLE -

eg. djm tells us that his lyra2v2 miner does 6 MH
public miner does 4.5 MH

We open up a unique BTC escrow address where everyone can "donate" to.
Everyone can follow the BTC amount in a block explorer.

Once the dev feels comfortable to release the code he will do so,
if not so be it, someone else will probably grab the escrow soon enough.

[Slava_K]

Lyra2REv2:

[2015-09-03 00:11:31] accepted: 65/66 (98.48%), 27603 kH/s (nooooo)
[2015-09-03 00:11:31] reject reason: Duplicate share.
[2015-09-03 00:11:31] enabling duplicates check feature
[2015-09-03 00:11:37] GPU #2: GeForce GTX 960, 5242
[2015-09-03 00:11:39] GPU #1: GeForce GTX 980, 11282
[2015-09-03 00:11:40] GPU #0: GeForce GTX 980, 10614
[2015-09-03 00:11:40] accepted: 66/67 (98.51%), 27332 kH/s (yes!!!)
[2015-09-03 00:11:41] accepted: 67/68 (98.53%), 27119 kH/s (yes!!!)
[2015-09-03 00:11:42] GPU #1: GeForce GTX 980, 11351
[2015-09-03 00:11:42] GPU #2: GeForce GTX 960, 6039
[2015-09-03 00:11:43] GPU #0: GeForce GTX 980, 10679
[2015-09-03 00:11:43] accepted: 68/69 (98.55%), 27335 kH/s (yes!!!)
[2015-09-03 00:11:44] accepted: 69/70 (98.57%), 27150 kH/s (yes!!!)
.......
[2015-09-03 00:13:45] GPU #1: GeForce GTX 980, 11442
[2015-09-03 00:13:46] accepted: 81/82 (98.78%), 27177 kH/s (yes!!!)
[2015-09-03 00:13:46] GPU #2: GeForce GTX 960, 6014
[2015-09-03 00:13:47] GPU #0: GeForce GTX 980, 10714
[2015-09-03 00:13:47] GPU #1: GeForce GTX 980, 11406
[2015-09-03 00:13:49] GPU #2: GeForce GTX 960, 6042
[2015-09-03 00:13:50] GPU #0: GeForce GTX 980, 10293
[2015-09-03 00:13:50] GPU #1: GeForce GTX 980, 11207
[2015-09-03 00:13:59] GPU #2: GeForce GTX 960, 6005
[2015-09-03 00:14:00] GPU #1: GeForce GTX 980, 11433
[2015-09-03 00:14:00] GPU #0: GeForce GTX 980, 10748
[2015-09-03 00:14:02] GPU #1: GeForce GTX 980, 11166
[2015-09-03 00:14:02] GPU #2: GeForce GTX 960, 5847
[2015-09-03 00:14:02] GPU #0: GeForce GTX 980, 10599
[2015-09-03 00:14:04] nonce 95ad2703 was already sent 44 seconds ago
[2015-09-03 00:14:05] GPU #1: GeForce GTX 980, 11408
[2015-09-03 00:14:05] GPU #0: GeForce GTX 980, 10748
[2015-09-03 00:14:05] GPU #2: GeForce GTX 960, 6025
[2015-09-03 00:14:08] GPU #0: GeForce GTX 980, 10376
[2015-09-03 00:14:08] GPU #1: GeForce GTX 980, 11395
[2015-09-03 00:14:08] GPU #2: GeForce GTX 960, 5952
[2015-09-03 00:14:10] GPU #0: GeForce GTX 980, 9597
[2015-09-03 00:14:10] GPU #1: GeForce GTX 980, 11207
[2015-09-03 00:14:12] GPU #2: GeForce GTX 960, 3660
[2015-09-03 00:14:13] GPU #0: GeForce GTX 980, 10680
[2015-09-03 00:14:13] GPU #1: GeForce GTX 980, 8560
[2015-09-03 00:14:15] GPU #2: GeForce GTX 960, 4690
[2015-09-03 00:14:16] GPU #1: GeForce GTX 980, 11357
[2015-09-03 00:14:16] GPU #0: GeForce GTX 980, 10782
[2015-09-03 00:14:17] nonce 88b38eb0 was already sent 45 seconds ago
[2015-09-03 00:14:18] GPU #2: GeForce GTX 960, 6019
[2015-09-03 00:14:18] GPU #1: GeForce GTX 980, 11363
[2015-09-03 00:14:18] GPU #0: GeForce GTX 980, 10519
[2015-09-03 00:14:21] GPU #2: GeForce GTX 960, 6006
[2015-09-03 00:14:21] GPU #1: GeForce GTX 980, 11376
[2015-09-03 00:14:21] GPU #0: GeForce GTX 980, 6173
[2015-09-03 00:14:23] GPU #1: GeForce GTX 980, 11357
[2015-09-03 00:14:23] GPU #2: GeForce GTX 960, 5990
[2015-09-03 00:14:24] GPU #0: GeForce GTX 980, 10731
[2015-09-03 00:14:26] GPU #1: GeForce GTX 980, 10816
[2015-09-03 00:14:26] GPU #2: GeForce GTX 960, 6019
[2015-09-03 00:14:27] GPU #0: GeForce GTX 980, 10667
[2015-09-03 00:14:28] GPU #1: GeForce GTX 980, 11357
[2015-09-03 00:14:29] GPU #2: GeForce GTX 960, 5574
[2015-09-03 00:14:29] GPU #0: GeForce GTX 980, 10581
[2015-09-03 00:14:30] GPU #1: GeForce GTX 980, 11403
[2015-09-03 00:14:31] nonce a60a4f13 was already sent 45 seconds ago
[2015-09-03 00:14:32] GPU #2: GeForce GTX 960, 6007
[2015-09-03 00:14:32] GPU #0: GeForce GTX 980, 10748
[2015-09-03 00:14:33] GPU #1: GeForce GTX 980, 11357
[2015-09-03 00:14:38] GPU #0: GeForce GTX 980, 10714
[2015-09-03 00:14:39] GPU #2: GeForce GTX 960, 6025
[2015-09-03 00:14:43] GPU #1: GeForce GTX 980, 11433
[2015-09-03 00:14:51] GPU #0: GeForce GTX 980, 10782
[2015-09-03 00:14:51] GPU #2: GeForce GTX 960, 5242
[2015-09-03 00:14:56] GPU #1: GeForce GTX 980, 11433
[2015-09-03 00:14:58] accepted: 82/83 (98.80%), 27761 kH/s (yes!!!)
[2015-09-03 00:14:58] stratum connection reset
[2015-09-03 00:14:59] Stratum difficulty set to 4

[sp_]

Lyra2REv2:
[2015-09-03 00:11:31] accepted: 65/66 (98.48%), 27603 kH/s (nooooo)
[2015-09-03 00:11:31] reject reason: Duplicate share.
[2015-09-03 00:11:31] enabling duplicates check feature

Yes. I think this is the same bug as the solomining bug. On nicehash no new blocks are comming and the diff is not changed, and then there is an overflow somewhere.

[djm34]

- Regarding developer work -

We should simply have a trusted escrow BTC address where we donate money to for a CERTAIN algo.

Once the dev thinks the escrow is worth grabbing he makes his work/code available as open source.
If it never reaches the threshold the dev thinks it's worth, then the escrow guy will refund the donators.

I would bet that a few btc would come together for each release.



This escrow model should be in BTC !!!
For smaller coins a % fee is utterly devastating to the coin itself cuz one guy (the miner dev) can dump below market price forever.


- EXAMPLE -

eg. djm tells us that his lyra2v2 miner does 6 MH
public miner does 4.5 MH

We open up a unique BTC escrow address where everyone can "donate" to.
Everyone can follow the BTC amount in a block explorer.

Once the dev feels comfortable to release the code he will do so,
if not so be it, someone else will probably grab the escrow soon enough.

you really don't trust the devs, you need an escrow and we might dump the fee below market
such a bad reputation.
well first for "new" coin/algo I clearly don't accept as payment some worthless new coin   (still have my doomcoin bounty, so you see I don't really dump and there is a lot more chances, that devs gets dumped on by many miners than the inverse...).
So the fee system is clearly only for reputable coins not every new coins.

And regarding the escrow, I did that (without escrow, although people were getting the miner before reaching the minimum) for neoscrypt.  
and it took quite a long time to get to a couple of btc.

also donating until a certain amount is reached is beneficial for a coin community not that much for the individual miners who wants to get an advantage over other miners. So basically unless it is a consensus from a coin community (meaning something faster is needed), you can't really expect much donation because if everybody gets the faster miner at the same time, it doesn't benefit to them hence no point donating... here the fee system is clearly a better solution.