CCminer(SP-MOD) Modded GPU kernels.

[Genoil]

I expect a significant etherum boost on compute 5.2 devices with my modded code.
But in a few months the dagger file will double in size, and most of the modern gpu's will suffer.

The DAG doesn't grow that fast. Compute 5.2 devices on Linux and win7 will be fine until the planned switch to POS (~1 year) as the 2GB threshold after which TLB trashing starts will take another 2+ years.
I do have a hard time believing you can significantly boost ethash, as it is memory bound and the keccak stages are already 'free'. I can run double the amount of keccak stages without losing hashrate...

Perhaps I could inject another algo in the pipeline. Merged mining. Sounds like you have many free cycles left. Nicehash is currently paying 0.0014 BTC for GHASH of keccek.

The problem is that keccak is a register hog. I can run ethash at about the same speed using between 64 and 80 registers.

[sp_]

I expect a significant etherum boost on compute 5.2 devices with my modded code.
But in a few months the dagger file will double in size, and most of the modern gpu's will suffer.

The DAG doesn't grow that fast. Compute 5.2 devices on Linux and win7 will be fine until the planned switch to POS (~1 year) as the 2GB threshold after which TLB trashing starts will take another 2+ years.
I do have a hard time believing you can significantly boost ethash, as it is memory bound and the keccak stages are already 'free'. I can run double the amount of keccak stages without losing hashrate...

Perhaps I could inject another algo in the pipeline. Merged mining. Sounds like you have many free cycles left. Nicehash is currently paying 0.0014 BTC for GHASH of keccek.

The problem is that keccak is a register hog. I can run ethash at about the same speed using between 64 and 80 registers.

You don't add code, you just change wich buffer the keccak pass is working on. Same code, free keccak. More BTC. But your mininer would need to connect to two pools at the same time.

[djm34]

I expect a significant etherum boost on compute 5.2 devices with my modded code.
But in a few months the dagger file will double in size, and most of the modern gpu's will suffer.

The DAG doesn't grow that fast. Compute 5.2 devices on Linux and win7 will be fine until the planned switch to POS (~1 year) as the 2GB threshold after which TLB trashing starts will take another 2+ years.
I do have a hard time believing you can significantly boost ethash, as it is memory bound and the keccak stages are already 'free'. I can run double the amount of keccak stages without losing hashrate...

Perhaps I could inject another algo in the pipeline. Merged mining. Sounds like you have many free cycles left. Nicehash is currently paying 0.0014 BTC for GHASH of keccek.

The problem is that keccak is a register hog. I can run ethash at about the same speed using between 64 and 80 registers.

You don't add code, you just change wich buffer the keccak pass is working on. Same code, free keccak. More BTC. But your mininer would need to connect to two pools at the same time.

I think it was already discussed few months ago... I don't think you would gain a lot here as keccak is already a lot faster than the rest of the algo

[djm34]

The --benchmark --time-limit 200 isn't working as is it supposed to.
You would expect ccminer to mine for 200 secs and display the average hashrate in the whole interval, but it is not.
It will simply mine for 200 secs, and display the average hashrate for the last second or so in the 200sec interval. Since the hashrate is fluctating alot, this will not give a correct output.
If somebody could correct this and create a average function of all the outputs to the commandline I could merge your changes into the main branch. Should be a 15min-30min job for a experienced C coder.

also sp - as i mentioned in the nicehash thread - would it be possible to add an eth kernel in ccminer-spmod? ...
even if its not an optimized one? ...
#crysx

Yes, I am planning to add genoils kernal, but I don't think I will add the code that generate the Dag file, so you need to generate this file with the original miner.

what would that do - if you did add the code? ...
that just sounds quite fiddly to me mate ...
#crysx

You just generate the Dag file, and this file will be valid for a while until the blocksize changes. So you can mine for weeks without changing the dagger.

A SIGNIFICANT ADDITION! --

Worth donations from all users.  I hope to see more about this soon!       --scryptr

(yeah will see that...)

[Genoil]

You can do CPU verification of it in 32-bit...

Yes but it is a lot of work. The eth core heavily depends on some big 64-bit libs.

You don't add code, you just change wich buffer the keccak pass is working on. Same code, free keccak. More BTC. But your mininer would need to connect to two pools at the same time.

You'd still need storage to swap out the keccak state. If you do that in global ram, you're only adding more latency instead of hiding it. In shared RAM, it's so much that it starts to press on occupancy.

I still need to look at some other potential oppurtunity for optimizing ETH (AMD only), but don't have much time now.

[sp_]

You can do CPU verification of it in 32-bit...

Yes but it is a lot of work. The eth core heavily depends on some big 64-bit libs.

You don't add code, you just change wich buffer the keccak pass is working on. Same code, free keccak. More BTC. But your mininer would need to connect to two pools at the same time.

You'd still need storage to swap out the keccak state. If you do that in global ram, you're only adding more latency instead of hiding it. In shared RAM, it's so much that it starts to press on occupancy.
I still need to look at some other potential oppurtunity for optimizing ETH (AMD only), but don't have much time now.

You only need to store when you find a nonce that produce a valid keccak hash. The nonce is just a 32bit integer and can be stored in the stack. (level 1 cache).
The merged mining could be a good way to hide donation mining.

[bensam1231]

You can do CPU verification of it in 32-bit...

Yes but it is a lot of work. The eth core heavily depends on some big 64-bit libs.

You don't add code, you just change wich buffer the keccak pass is working on. Same code, free keccak. More BTC. But your mininer would need to connect to two pools at the same time.

You'd still need storage to swap out the keccak state. If you do that in global ram, you're only adding more latency instead of hiding it. In shared RAM, it's so much that it starts to press on occupancy.
I still need to look at some other potential oppurtunity for optimizing ETH (AMD only), but don't have much time now.

You only need to store when you find a nonce that produce a valid keccak hash. The nonce is just a 32bit integer and can be stored in the stack. (level 1 cache).
The merged mining could be a good way to hide donation mining.

Neat way of dealing with the memory limitations of Eth. Kudos on that BTW. I'm guessing merged mining isn't really a option for the majority of algos as they more fully utilize GPUs? What about for other memory intensive algos, like Cryptonote?


In other news, does anyone in here have experience with making coins or know anyone who would be a good contact for that? I'm looking into making my own, but would need someone with knowledge of making coins (not just copy paste). The coin wouldn't have to be anything special and could probably just clone another popular coin, however the usage of it would be completely different as would the distribution (but once again nothing super special). Some backend code would have to be written to do a few special things I have in mind, but very easy stuff. I could probably do myself, but it has to tie into the coin which complicates things and I have a lot on my plate besides this.

I'm trying to be vague, wouldn't mind talking with someone on here if you're interested. I don't have a lot in the way of monetary value, so it would probably be payment in the form of the currency we're making (which is monopoly money till things get going). Time frame would definitely be generous, but within reason. There may be a v2/3 of the coin as well depending on how the first generation goes. This has been something I've been planning for well over a year and isn't going to be a ordinary pump/dump coin.

If you guys have a referral, I'd take that too.

[sp_]

Here is some of the popular algos and their speed measurements with the 20 latest sp-mod releases on the 750ti. (EVGA GTX 750 Ti standard clocks)

http://cryptomining-blog.com/6289-evga-gtx-750-ti-with-different-versions-of-ccminer-spmod/





July 2015-november 2015

x11: +2%
quark: +6.2%
neo:    +8.3%
lyra2v2: +5.3%

But as you can see, the release 74 might not be the fastest in all algos.

x11(release 74) (+2%)
quark (release 70) (+6.73)%
neo (release 70) (+8.93)%
lyra2v2(release 67)(+6.7%)

[Genoil]

You can do CPU verification of it in 32-bit...

Yes but it is a lot of work. The eth core heavily depends on some big 64-bit libs.

You don't add code, you just change wich buffer the keccak pass is working on. Same code, free keccak. More BTC. But your mininer would need to connect to two pools at the same time.

You'd still need storage to swap out the keccak state. If you do that in global ram, you're only adding more latency instead of hiding it. In shared RAM, it's so much that it starts to press on occupancy.
I still need to look at some other potential oppurtunity for optimizing ETH (AMD only), but don't have much time now.

You only need to store when you find a nonce that produce a valid keccak hash. The nonce is just a 32bit integer and can be stored in the stack. (level 1 cache).
The merged mining could be a good way to hide donation mining.

Ethash nonce is 64-bit but that's still small. But on second thought you may be right, I was looking at the wrong end. If you simply do a couple of rounds of keccak after ethash already has completed, it could work! I'd say go for it :-)

[Genoil]

Thinking about it a bit more, the easiest way forward would be to extend ethminer with a stratum proxy that ccminer would connect to. Ethminer would take care of DAG creation, CPU verification and work supply. It would be very low on resources.

[pallas]

Thinking about it a bit more, the easiest way forward would be to extend ethminer with a stratum proxy that ccminer would connect to. Ethminer would take care of DAG creation, CPU verification and work supply. It would be very low on resources.

Looks like a fine idea to me :-)

[antonio8]

Thinking about it a bit more, the easiest way forward would be to extend ethminer with a stratum proxy that ccminer would connect to. Ethminer would take care of DAG creation, CPU verification and work supply. It would be very low on resources.

If I am thinking correct then that would be Dwarf Pool as the only pool with a stratum. I could be wrong also if that is not what you meant.

[jpouza]

Here is some of the popular algos and their speed measurements with the 20 latest sp-mod releases on the 750ti. (EVGA GTX 750 Ti standard clocks)

http://cryptomining-blog.com/6289-evga-gtx-750-ti-with-different-versions-of-ccminer-spmod/





July 2015-november 2015

x11: +2%
quark: +6.2%
neo:    +8.3%
lyra2v2: +5.3%

But as you can see, the release 74 might not be the fastest in all algos.

x11(release 74) (+2%)
quark (release 70) (+6.73)%
neo (release 70) (+8.93)%
lyra2v2(release 67)(+6.7%)

sp_, it is really nice to see the progress / improvements here, I can see you haven´t stopped developing the ccminer algos, my only regret is to do not participate anymore in this journey testing the miners and contributing with donations, I really wish sucess to you all, keep up the good work.


Cheers

[pallas]

sp_, it is really nice to see the progress / improvements here, I can see you haven´t stopped developing the ccminer algos, my only regret is to do not participate anymore in this journey testing the miners and contributing with donations, I really wish sucess to you all, keep up the good work.

Cheers

If the profit continues dropping like this, we may all have to stop mining/developing :-(

[jpouza]

sp_, it is really nice to see the progress / improvements here, I can see you haven´t stopped developing the ccminer algos, my only regret is to do not participate anymore in this journey testing the miners and contributing with donations, I really wish sucess to you all, keep up the good work.

Cheers

If the profit continues dropping like this, we may all have to stop mining/developing :-(

That is a pitty, I have stopped mining here cause of government taxes (Electricity bill).

[Genoil]

Thinking about it a bit more, the easiest way forward would be to extend ethminer with a stratum proxy that ccminer would connect to. Ethminer would take care of DAG creation, CPU verification and work supply. It would be very low on resources.

If I am thinking correct then that would be Dwarf Pool as the only pool with a stratum. I could be wrong also if that is not what you meant.

No it would be like this:
Ccminer <-> stratum <-> ethminer <-> ETH::getWork <-> any pool or ETH node

[bensam1231]

sp_, it is really nice to see the progress / improvements here, I can see you haven´t stopped developing the ccminer algos, my only regret is to do not participate anymore in this journey testing the miners and contributing with donations, I really wish sucess to you all, keep up the good work.

Cheers

If the profit continues dropping like this, we may all have to stop mining/developing :-(

That is a pitty, I have stopped mining here cause of government taxes (Electricity bill).

Yup it's getting there... A lot of volume is being dumped into BTC as it continues to climb. Altcoins may be left at the wayside in lieu of the mothercoin. Hopefully not, but we'll see.

Bump for this

In other news, does anyone in here have experience with making coins or know anyone who would be a good contact for that? I'm looking into making my own, but would need someone with knowledge of making coins (not just copy paste). The coin wouldn't have to be anything special and could probably just clone another popular coin, however the usage of it would be completely different as would the distribution (but once again nothing super special). Some backend code would have to be written to do a few special things I have in mind, but very easy stuff. I could probably do myself, but it has to tie into the coin which complicates things and I have a lot on my plate besides this.

I'm trying to be vague, wouldn't mind talking with someone on here if you're interested. I don't have a lot in the way of monetary value, so it would probably be payment in the form of the currency we're making (which is monopoly money till things get going). Time frame would definitely be generous, but within reason. There may be a v2/3 of the coin as well depending on how the first generation goes. This has been something I've been planning for well over a year and isn't going to be a ordinary pump/dump coin.

If you guys have a referral, I'd take that too.

[bathrobehero]

Yup it's getting there... A lot of volume is being dumped into BTC as it continues to climb. Altcoins may be left at the wayside in lieu of the mothercoin. Hopefully not, but we'll see.

I can't help but feel that when the price of BTC will increase next year mostly becasue of the halving, it should inevitably create interest in the crypto scene which should revive altcoins as well. Hopefully at least.

[Cryptozillah]

Some Black Friday 970:s arrived today.

[chrysophylax]

sp_, it is really nice to see the progress / improvements here, I can see you haven´t stopped developing the ccminer algos, my only regret is to do not participate anymore in this journey testing the miners and contributing with donations, I really wish sucess to you all, keep up the good work.

Cheers

If the profit continues dropping like this, we may all have to stop mining/developing :-(

i wont ... ...

off to bed now ... nite ...

#crysx