ok I added it now. You have to build yourself..
The gtx 970 is doing 2.3GHASH
Run with -a vanilla
Run with -a vanilla
Gtx 970: 2.6GHASH
Gtx 960: 1.65GHASH
gtx 750ti: 0.94GHASH
Topic: CCminer(SP-MOD) Modded NVIDIA Maxwell / Pascal kernels. - page 780. (Read 2347664 times)
Gtx 970: 2.6GHASH
Gtx 960: 1.65GHASH
gtx 750ti: 0.94GHASH
1. Download cuda 7.5
2. Download and install visual studio 2013 express
3. Download the source: https://github.com/sp-hash/ccminer/archive/windows.zip
3. Open the project. select release, win32
4. Build.
2. Download and install visual studio 2013 express
3. Download the source: https://github.com/sp-hash/ccminer/archive/windows.zip
3. Open the project. select release, win32
4. Build.
ok I added it now. You have to build yourself..
The gtx 970 is doing 2.3GHASH
Run with -a vanilla
The gtx 970 is doing 2.3GHASH
Run with -a vanilla
Thank you - what is the software used to build from source again?
ok I added it now. You have to build yourself..
The gtx 970 is doing 2.3GHASH
Run with -a vanilla
The gtx 970 is doing 2.3GHASH
Run with -a vanilla
SP will you be incorporating the new vanilla blake algo into ccminer? If so, when?
Blake is already included. ccminer -a blake --benchmark or ccminer -a blakecoin --benchmark
No - they have modified the file somehow to be vanilla-blake.
xCore - ccminer GTX9xx/750 (based on last sp-hash's github): https://talk.vanillacoin.net/uploads/files/tools/ccminer-1.7.1-blake256-standard-uncompressed-sp.zip
-pokeytex
I don't remember it was released either (I remember that I tested it though...) I think it was on a dropbox or something , don't think he created a repo (?)
I found the code on github:
https://github.com/tpruvot/ccminer/tree/ethash
ethash test to finish...
remains the mixHash thing to compute, and to check the submitted nonce64 endian/value
Signed-off-by: Tanguy Pruvot <[email protected]>
I believe Epsylon3/tpruvot has been trying to get a 32-bit version of ethminer to work a while back. Can't find the source anymore.
I tried as well to integrate the ether miner into ccminer.. But lost interest because the 64bit nonce and other non standard code. I can do another try and release the result.
NO cpu verification or DAG generation. Only to test and mod the gpu code.. (--benchmark mode)
Perhaps compile the ether miner for 32 bit's will help? Cached Pointersizes will go from 64bit to 32 (and double the tlb limit?) You need to remove the cpu verfication code because it use 64bit libraries I think..
Thought of that but it's going to be troublesome. You only have a 4GB address space, with windows already sucking up ~half. Then you have to load the 1.3 GB DAG from disk, and allocate 1.3GB of GPU RAM (which, AFAIK sits in the same space, although it isn't pinned to host). This doens't fit. So then you would have to read the DAG from disk in small chunks and copy it cover to GPU RAM. And when that's all done, you will have to pass on all solutions to a special light version of ethminer, that does light verification, is it can't load a DAG into RAM for the same reasons. Or you simply don't verify and risk some Boo's.
Then, when that's all done, you're not even sure if it fixes the problem. You could try getting a 32-bit version of dagSimCL to work.
I believe Epsylon3/tpruvot has been trying to get a 32-bit version of ethminer to work a while back. Can't find the source anymore.
Perhaps compile the ether miner for 32 bit's will help? Cached Pointersizes will go from 64bit to 32 (and double the tlb limit?) You need to remove the cpu verfication code because it use 64bit libraries I think..
Thought of that but it's going to be troublesome. You only have a 4GB address space, with windows already sucking up ~half. Then you have to load the 1.3 GB DAG from disk, and allocate 1.3GB of GPU RAM (which, AFAIK sits in the same space, although it isn't pinned to host). This doens't fit. So then you would have to read the DAG from disk in small chunks and copy it cover to GPU RAM. And when that's all done, you will have to pass on all solutions to a special light version of ethminer, that does light verification, is it can't load a DAG into RAM for the same reasons. Or you simply don't verify and risk some Boo's.
Then, when that's all done, you're not even sure if it fixes the problem. You could try getting a 32-bit version of dagSimCL to work.
I believe Epsylon3/tpruvot has been trying to get a 32-bit version of ethminer to work a while back. Can't find the source anymore.
Samsung and Elpida give 20-22MH/s, hynix 17-19MH/s in windows 7. I am not sure about windows 8.1.
You need to get your card to P0 state:
1) open cmd.exe with the admin privileges
2) cd C:\Program Files\NVIDIA Corporation\NVSMI
3) nvidia-smi -q -d SUPPORTED_CLOCKS -i 0
4) nvidia-smi -ac 350X,14XX -i 0 (where 350X is that very first number printed after supported clocks-memory and 14XX one of those numbers printed after graphics)
5) Overclock your memory, +500 generally works. Should give you memory speed of 4005MHz
6) Overclock your core, doesn't make big difference mining ETH.
7) If you wan't to save power, reduce your power limit. Even 60% works suprisingly well.
Someone should open new topic for nvidia and ethereum...
Thanks, now my gtx970 card gives ~21Mh
Overclock: nvidia-smi -ac 3505,1505
Startup parametrs eth miner: ethminer --cuda-grid-size 8192 --cuda-block-size 128 --cuda-turbo
SP will you be incorporating the new vanilla blake algo into ccminer? If so, when?
Blake is already included. ccminer -a blake --benchmark or ccminer -a blakecoin --benchmark
I don't think it'll work.
You should import a little patch which was submitted to tpruvot ccminer a couple days ago.
EDIT:
"Algo is the same Blake256 8-rounds. It's just different from Blakecoin who's using single sha256 for the merkle root generation. Vanilla will use standard double sha256."
Had the same issue, reverted to 0.9.4.1 (from cryptominingblog) which is a bit slower but submit shares.
Regarding 750 Ti's, I get like 300khs every 5th or 6th lines amd the rest is just zeros.
Regarding 750 Ti's, I get like 300khs every 5th or 6th lines amd the rest is just zeros.
Did you try the opencl version with adjustable blocksize?
https://github.com/Genoil/cpp-ethereum/tree/opencl-chunks
Chunks version does work on NVidia (not on AMD!), but AFAIK it doesn't do anything to avert TLB trashing.
I wonder what's the difference between these versions. I also get reports from people using a build posted on cryptomining who can't submit shares. If I'm correct, there are actually two different builds posted on Cryptomining. I'll try them both.
To rule out a problem with the algo, try running the miner for a while using the -S flag instead of -F. It simulates hashing at increasing difficulty until a block time of 15 seconds is reached. Using a GTX9x0, you should be able to get to a difficulty of about 30 (1 << 30) in a relatively short amount of time. If you get stuck at 20 or 25, the algo is most likely broken. Don't be fooled if it makes your 750ti tick hash faster on Win7/Linux than it does now as it uses the epoch 0 DAG.
Had the same issue, reverted to 0.9.4.1 (from cryptominingblog) which is a bit slower but submit shares.
Regarding 750 Ti's, I get like 300khs every 5th or 6th lines amd the rest is just zeros.
Regarding 750 Ti's, I get like 300khs every 5th or 6th lines amd the rest is just zeros.
Did you try the opencl version with adjustable blocksize?
https://github.com/Genoil/cpp-ethereum/tree/opencl-chunks
Remember, it is a race for finding a block which starts again every 15 seconds. To win that race you need to get rid of every ms. To mine directly to exchange you need to mine in pool, pool = lots of ms and rejected shares.
From my experience with fast coins it's the other way around; you get more orphans not the pools, even with very low scantime. Pools tend to have better connection and their wallets usually have way more than 10-20 connections.
Yeah, forgot to say you need better than average network connection too. You just don't wan't to see pool stats like this (ETH):
Blocks Coins Generated
13 65
5 25
Earnings
58.51884072
SP will you be incorporating the new vanilla blake algo into ccminer? If so, when?
Blake is already included. ccminer -a blake --benchmark or ccminer -a blakecoin --benchmark
Let me guess, your 970 has Hynix memory?
Samsung. Gigabyte cards.
Remember, it is a race for finding a block which starts again every 15 seconds. To win that race you need to get rid of every ms. To mine directly to exchange you need to mine in pool, pool = lots of ms and rejected shares.
From my experience with fast coins it's the other way around; you get more orphans not the pools, even with very low scantime. Pools tend to have better connection and their wallets usually have way more than 10-20 connections.
yep I have the same issue ...
not a single share is submitted ...
not a single share is submitted ...
Had the same issue, reverted to 0.9.4.1 (from cryptominingblog) which is a bit slower but submit shares.
Regarding 750 Ti's, I get like 300khs every 5th or 6th lines amd the rest is just zeros.
Splitting up the Dag file would help. "i think".
Feel kind of bad for the nvidia guys out there but glad i don't own any.
Feel kind of bad for the nvidia guys out there but glad i don't own any.
If more miners are moving to mine Etherum, then the other algos will be more profitable.
This depends entirely on who is moving. I've seen relatively no change in other algos profitability, this means people that are moving are using pub kernels (much like us) and profitability is much higher for Eth. If they aren't moving, that probably means profitability is higher for whatever they're mining (like x11 for instance), which means they're using custom kernels and rightfully so network difficulty doesn't change much as they control the majority of the market hashrate.
I don't believe in miners that don't watch their profits. Usually everything adjusts in about 3~ days.
Too Complicated: People are using custom kernels, they're still making more mining what they currently are.
In other news, Eth is crashing, Lyra is making a comeback...
You are right.
I always wondered why would anyone want to mine an unprofitable algo (based on sp's ccminer hashrates for example).
The reason must be that whoever is mining those algos has access to private miners.
Yup, in some cases it's botnets too. For instance Neoscrypt has a CPU miner that's still somewhat profitable as does Cryptonote, so they mine negative. I'm pretty sure we'll never see Monero profitable ever again. X11 is definitely full of private kernels.
SP will you be incorporating the new vanilla blake algo into ccminer? If so, when?
Splitting up the Dag file would help. "i think".
Feel kind of bad for the nvidia guys out there but glad i don't own any.
Feel kind of bad for the nvidia guys out there but glad i don't own any.
If more miners are moving to mine Etherum, then the other algos will be more profitable.
This depends entirely on who is moving. I've seen relatively no change in other algos profitability, this means people that are moving are using pub kernels (much like us) and profitability is much higher for Eth. If they aren't moving, that probably means profitability is higher for whatever they're mining (like x11 for instance), which means they're using custom kernels and rightfully so network difficulty doesn't change much as they control the majority of the market hashrate.
I don't believe in miners that don't watch their profits. Usually everything adjusts in about 3~ days.
Too Complicated: People are using custom kernels, they're still making more mining what they currently are.
In other news, Eth is crashing, Lyra is making a comeback...
You are right.
I always wondered why would anyone want to mine an unprofitable algo (based on sp's ccminer hashrates for example).
The reason must be that whoever is mining those algos has access to private miners.
Splitting up the Dag file would help. "i think".
Feel kind of bad for the nvidia guys out there but glad i don't own any.
Feel kind of bad for the nvidia guys out there but glad i don't own any.
If more miners are moving to mine Etherum, then the other algos will be more profitable.
This depends entirely on who is moving. I've seen relatively no change in other algos profitability, this means people that are moving are using pub kernels (much like us) and profitability is much higher for Eth. If they aren't moving, that probably means profitability is higher for whatever they're mining (like x11 for instance), which means they're using custom kernels and rightfully so network difficulty doesn't change much as they control the majority of the market hashrate.
I don't believe in miners that don't watch their profits. Usually everything adjusts in about 3~ days.
Too Complicated: People are using custom kernels, they're still making more mining what they currently are.
In other news, Eth is crashing, Lyra is making a comeback...
Jump to: