CCminer(SP-MOD) Modded GPU kernels.

[sp_]

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.

[chrysophylax]

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

[sp_]

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.

[chrysophylax]

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

[pallas]

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

I think you'd need to periodically run the eth miner to generate the dag files, so ccminer can use them.

[sp_]

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.

[scryptr]

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

[chrysophylax]

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

ill always donate anyway ...

but yes - agreed ... i still think it would be worth it to have the whole thing in ONE miner ...

it always seems to be the same situation for me ... where if you had one or two machines mining - that would be easy to do - but a farm is more trouble than its worth ... it really is ...

one miner that does it all ... thats my vote ...

#crysx

[sp_]

ill always donate anyway ...

but yes - agreed ... i still think it would be worth it to have the whole thing in ONE miner ...

it always seems to be the same situation for me ... where if you had one or two machines mining - that would be easy to do - but a farm is more trouble than its worth ... it really is ...

one miner that does it all ... thats my vote ...

#crysx

yes, the goal in the end must be one miner that does it all. But first, I will just add the kernal  with some limitations. (less work)

[miningpoolhub]

Hi
I'm trying sp-mod ccminer first time and maybe I misunderstood something.

When I try to mine with myr-grs algo, it doesn't work and only getting low difficulty shares.
Seems like diff multiplier is different than other ccminer versions or hashing is totally making wrong values.


ccminer.exe -a myr-gr -o stratum+tcp://hub.miningpoolhub.com:20479 -u username.workername -p x


But when I mine with ccminer by tpruvot v1.6.2, it works well.

[AliMan]

Hi
I'm trying sp-mod ccminer first time and maybe I misunderstood something.

When I try to mine with myr-grs algo, it doesn't work and only getting low difficulty shares.
Seems like diff multiplier is different than other ccminer versions or hashing is totally making wrong values.


ccminer.exe -a myr-gr -o stratum+tcp://hub.miningpoolhub.com:20479 -u username.workername -p x


But when I mine with ccminer by tpruvot v1.6.2, it works well.

I believe its broken.

[sp_]

try with --diff 256 or --diff 0.00390625

[bathrobehero]

try with --diff 256 or --diff 0.00390625

Yep, it's 0.00390625 (1/256). --diff is a difficulty divider so 256 would decrease the difficulty even more causing more low difficulty shares.

It's not neccessarily a problem with ccminer, it's just the pool and ccminer using different standards.

[Genoil]

ill always donate anyway ...

but yes - agreed ... i still think it would be worth it to have the whole thing in ONE miner ...

it always seems to be the same situation for me ... where if you had one or two machines mining - that would be easy to do - but a farm is more trouble than its worth ... it really is ...

one miner that does it all ... thats my vote ...

#crysx

yes, the goal in the end must be one miner that does it all. But first, I will just add the kernal  with some limitations. (less work)

If you drop the CPU verification of solutions and load the DAG in chunks, it might work in 32-bit, otherwise you would need to build a 64bit ccminer. I have understood that is suboptimal for some other algo's .

[chrysophylax]

ill always donate anyway ...

but yes - agreed ... i still think it would be worth it to have the whole thing in ONE miner ...

it always seems to be the same situation for me ... where if you had one or two machines mining - that would be easy to do - but a farm is more trouble than its worth ... it really is ...

one miner that does it all ... thats my vote ...

#crysx

yes, the goal in the end must be one miner that does it all. But first, I will just add the kernal  with some limitations. (less work)

If you drop the CPU verification of solutions and load the DAG in chunks, it might work in 32-bit, otherwise you would need to build a 64bit ccminer. I have understood that is suboptimal for some other algo's .

the main reason i would prefer to have it in the one miner is obviously that it makes it easier to mine under the one miner ...

it would be beneficial also for not only the 'green' miners - but also the advanced as well ...

hope to see it soon ...

#crysx

[bensam1231]

Hmmm people are going back to Ethereum? I was looking at Eth and it still looks about on par with Neoscrypt right now as far as how much you can make. No improvements have been made on Eth due to memory limitations. Everything is in the shitter currently. I guess you can throw your hat in whatever ring you want and you're probably not going to gain/lose much.

I assume everyone isn't mining in super secret Lyra/Neo/Eth private kernels?

BTW if anyone has a Overwatch account available I'd be willing to buy it from them in BTC. Of course you have to be active on the forums and have some street cred.

[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.

[dominuspro]

Hmmm people are going back to Ethereum? I was looking at Eth and it still looks about on par with Neoscrypt right now as far as how much you can make. No improvements have been made on Eth due to memory limitations. Everything is in the shitter currently. I guess you can throw your hat in whatever ring you want and you're probably not going to gain/lose much.

I assume everyone isn't mining in super secret Lyra/Neo/Eth private kernels?

BTW if anyone has a Overwatch account available I'd be willing to buy it from them in BTC. Of course you have to be active on the forums and have some street cred.

Eth maxwell mining means much lower power usage, temps and vent speeds in comparision to neoscrypt or quark.

[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...



 

[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-DAY of keccak.