Ok so apparently the current binaries don't work on (some) GTX9x0. They do work on my GTX780, so it's very hard to debug. I'm going to see if I can get my hands on that type of card. But if anybody has a Windows 7 system with 8GB RAM and a 9x0 card available that I can remote into, please PM me.
Hi Guys I've recently tried using an old unwanted R9 280x from my cousin to mine ETH. Previously I've used my GTX 970 on Windows 10 and managed to get ethminer running but it was sluggish at 7mhs
I'm now having problems with even getting the R9 280x to run on this windows 10 and can't seem to get it to even get ethminer to stay open. After opening it it just pops close in some instances, while others run for a but then crashes showing DAG generation failed.
@sebstar I think you should be able to get more out of the 660s using my cudaminer-uint64 branch. I dropped Compute 3.0 support from the (main) cudaminer-frontier branch, but that branch has some nice CPU saving code.
Thanks for the hint! This branch seems rather outdated, is its ethminer still compatible with the current ethereum network? I am the same guy who recently openen the cmake issue on github btw.
Building fails for me:
[ 10%] Building NVCC (Device) object libethash-cu/CMakeFiles/ethash-cu.dir/ethash-cu_generated_ethash_cu_miner_kernel.cu.o nvcc fatal : redefinition of argument 'std' CMake Error at ethash-cu_generated_ethash_cu_miner_kernel.cu.o.cmake:207 (message): Error generating /home/XXX/build/cpp-ethereum/build/libethash-cu/CMakeFiles/ethash-cu.dir//./ethash-cu_generated_ethash_cu_miner_kernel.cu.o
Hi Guys I've recently tried using an old unwanted R9 280x from my cousin to mine ETH. Previously I've used my GTX 970 on Windows 10 and managed to get ethminer running but it was sluggish at 7mhs
I'm now having problems with even getting the R9 280x to run on this windows 10 and can't seem to get it to even get ethminer to stay open. After opening it it just pops close in some instances, while others run for a but then crashes showing DAG generation failed.
Anyone know what's happening?
R9 is an AMD Card, you shouldn't use CUDA mining software for that. Use the upstream OpenCL ethminer instead.
Hi Guys I've recently tried using an old unwanted R9 280x from my cousin to mine ETH. Previously I've used my GTX 970 on Windows 10 and managed to get ethminer running but it was sluggish at 7mhs
I'm now having problems with even getting the R9 280x to run on this windows 10 and can't seem to get it to even get ethminer to stay open. After opening it it just pops close in some instances, while others run for a but then crashes showing DAG generation failed.
Anyone know what's happening?
R9 is an AMD Card, you shouldn't use CUDA mining software for that. Use the upstream ethminer instead.
Yup I'm finally able to get it to work using custom Ethminer, however being on windows 10 for this GPU, I'm wondering if there's any way to increase my hashrate from 13mhs to the actual expected 22 mhs?
I know this is related to the DAG size and Win10 being demanding for the space, but is there a workaround it?
@sebstar I think you should be able to get more out of the 660s using my cudaminer-uint64 branch. I dropped Compute 3.0 support from the (main) cudaminer-frontier branch, but that branch has some nice CPU saving code.
Thanks for the hint! This branch seems rather outdated, is its ethminer still compatible with the current ethereum network? I am the same guy who recently openen the cmake issue on github btw.
Building fails for me:
[ 10%] Building NVCC (Device) object libethash-cu/CMakeFiles/ethash-cu.dir/ethash-cu_generated_ethash_cu_miner_kernel.cu.o nvcc fatal : redefinition of argument 'std' CMake Error at ethash-cu_generated_ethash_cu_miner_kernel.cu.o.cmake:207 (message): Error generating /home/XXX/build/cpp-ethereum/build/libethash-cu/CMakeFiles/ethash-cu.dir//./ethash-cu_generated_ethash_cu_miner_kernel.cu.o
The reason I'm not going to sync my code with the webthree-umbrella is that I spent a lot of time on getting a PR ready for the Frontier launch (hence the branch name cudaminer-frontier) and all ETH::DEV could respond with was nitpicking about coding style. Understandable, but I had expected a little bit of effort on their end to merge it in.
I've done a bit of cleaning up on the repo. There are just two branches left:
compute30. It is a rather old branch and needs to be patched up with the cuda scheduling stuff. But it is the best performing branch on Compute 3.0 devices because it user uint64 instead of uint2 for holding the state.
@sebstar I think you should be able to get more out of the 660s using my cudaminer-uint64 branch. I dropped Compute 3.0 support from the (main) cudaminer-frontier branch, but that branch has some nice CPU saving code.
Thanks for the hint! This branch seems rather outdated, is its ethminer still compatible with the current ethereum network? I am the same guy who recently openen the cmake issue on github btw.
Building fails for me:
[ 10%] Building NVCC (Device) object libethash-cu/CMakeFiles/ethash-cu.dir/ethash-cu_generated_ethash_cu_miner_kernel.cu.o nvcc fatal : redefinition of argument 'std' CMake Error at ethash-cu_generated_ethash_cu_miner_kernel.cu.o.cmake:207 (message): Error generating /home/XXX/build/cpp-ethereum/build/libethash-cu/CMakeFiles/ethash-cu.dir//./ethash-cu_generated_ethash_cu_miner_kernel.cu.o
The reason I'm not going to sync my code with the webthree-umbrella is that I spent a lot of time on getting a PR ready for the Frontier launch (hence the branch name cudaminer-frontier) and all ETH::DEV could respond with was nitpicking about coding style. Understandable, but I had expected a little bit of effort on their end to merge it in.
I've done a bit of cleaning up on the repo. There are just two branches left:
compute30. It is a rather old branch and needs to be patched up with the cuda scheduling stuff. But it is the best performing branch on Compute 3.0 devices because it user uint64 instead of uint2 for holding the state.
@Genoil I've copied your stuff and pasted in the folder which I'm usually farming on, replacing all the files that you've provided that is duplicate with the old ones. (Not sure if that works)
I've then tried running the ethminer pooled to dwarfpool and it is submitting shares. That was on my GTX970 on Windows 7 64bit running on 8GB ram.
I'm not sure if the speed is faster though because the hashrate keeps alternating between 14mhs and 19mhs using your updated files.
I've also tried it out on the R9 280x on the windows 10 computer but it did not speed up nor fix the issue with the card running slow on Windows 10 similar to the 970 last time when it was on this windows 10 too. Also the R9 280x seems to be experiencing an alternating hashrate just like the 970 between 11mhs and 15mhs this time using your new files.
Hope this helps. Also hopefully there's a workaround windows 10 I don't want to buy another windows 7 just to mine on this pc
The reason I'm not going to sync my code with the webthree-umbrella is that I spent a lot of time on getting a PR ready for the Frontier launch (hence the branch name cudaminer-frontier) and all ETH::DEV could respond with was nitpicking about coding style. Understandable, but I had expected a little bit of effort on their end to merge it in.
I've done a bit of cleaning up on the repo. There are just two branches left:
compute30. It is a rather old branch and needs to be patched up with the cuda scheduling stuff. But it is the best performing branch on Compute 3.0 devices because it user uint64 instead of uint2 for holding the state.
I understand the frustration on your end - doesn't really motivate outsiders to get involved in the project on the coding side...
Thanks for the cleanup! Since a GTX 660 supports Compute 3.0, I guess I will give this (old) branch a shot. Does it still work? You mentioned that it needs to be patched up...
The 0.9.41-genoil-1.0.1 seems to work on Windows 10 on my 970:
D:\Etherium\ethminer-0.9.41-genoil-1.0.1>ethminer.exe -G --opencl-platform 1 -F http://ethereumpool.co/[email protected]
Found suitable OpenCL device [GeForce GTX 970] with 4294967296 bytes of GPU memory
miner 07:19:14|main Getting work package...
miner 07:19:14|main Grabbing DAG for #1842cb89
miner 07:19:15|main Got work package:
i 07:19:15| Loading full DAG of seedhash: #7e7d8bef
miner 07:19:15|main Header-hash: 3a12900e569f34bf062059c5d783f5ebc267965c982a44772baa788adcb16bf6
miner 07:19:15|main Seedhash: 1842cb89c0dfad7efb5ce2bf93f418e369214e9e1773a1bfe7c9c72ceee682bb
miner 07:19:15|main Target: 0000000262d6fcb00f94a711bf23bd0b6d41b9bd4bbd4c4c76afaff356ca7ef3
i 07:19:15|gpuminer0 workLoop 0 #00000000 #1842cb89
i 07:19:15|gpuminer0 Initialising miner...
miner 07:19:16|main Mining on PoWhash #3a12900e : 0 H/s = 0 hashes / 0.5 s
Using platform: NVIDIA CUDA
i 07:19:16| Full DAG loaded
Using device: GeForce GTX 970(OpenCL 1.2 CUDA)
miner 07:19:16|main Mining on PoWhash #3a12900e : 0 H/s = 0 hashes / 0.831 s
Printing program log
Creating one big buffer for the DAG
Loading single big chunk kernels
Mapping one big chunk.
miner 07:19:17|main Mining on PoWhash #3a12900e : 0 H/s = 0 hashes / 0.811 s
Creating buffer for header.
Creating mining buffer 0
Creating mining buffer 1
miner 07:19:18|main Mining on PoWhash #3a12900e : 3898052 H/s = 3145728 hashes / 0.807 s
miner 07:19:19|main Mining on PoWhash #3a12900e : 7757652 H/s = 6291456 hashes / 0.811 s
miner 07:19:20|main Mining on PoWhash #3a12900e : 7182027 H/s = 6291456 hashes / 0.876 s
miner 07:19:21|main Mining on PoWhash #3a12900e : 7767229 H/s = 6291456 hashes / 0.81 s
miner 07:19:21|main Mining on PoWhash #3a12900e : 7815473 H/s = 6291456 hashes / 0.805 s
miner 07:19:22|main Mining on PoWhash #3a12900e : 7757652 H/s = 6291456 hashes / 0.811 s
miner 07:19:23|main Mining on PoWhash #3a12900e : 6504813 H/s = 5242880 hashes / 0.806 s
miner 07:19:24|main Mining on PoWhash #3a12900e : 7607564 H/s = 6291456 hashes / 0.827 s
miner 07:19:25|main Mining on PoWhash #3a12900e : 7719577 H/s = 6291456 hashes / 0.815 s
Same weirdness as with the official version -- it benches at about 18 MH/s but running for real only manages what you see above, about 7.7 MH/s. At least the inconsistency is consistent between the two versions, though!
The 0.9.41-genoil-1.0.1 seems to work on Windows 10 on my 970:
D:\Etherium\ethminer-0.9.41-genoil-1.0.1>ethminer.exe -G --opencl-platform 1 -F http://ethereumpool.co/[email protected]
Found suitable OpenCL device [GeForce GTX 970] with 4294967296 bytes of GPU memory
miner 07:19:14|main Getting work package...
miner 07:19:14|main Grabbing DAG for #1842cb89
miner 07:19:15|main Got work package:
i 07:19:15| Loading full DAG of seedhash: #7e7d8bef
miner 07:19:15|main Header-hash: 3a12900e569f34bf062059c5d783f5ebc267965c982a44772baa788adcb16bf6
miner 07:19:15|main Seedhash: 1842cb89c0dfad7efb5ce2bf93f418e369214e9e1773a1bfe7c9c72ceee682bb
miner 07:19:15|main Target: 0000000262d6fcb00f94a711bf23bd0b6d41b9bd4bbd4c4c76afaff356ca7ef3
i 07:19:15|gpuminer0 workLoop 0 #00000000 #1842cb89
i 07:19:15|gpuminer0 Initialising miner...
miner 07:19:16|main Mining on PoWhash #3a12900e : 0 H/s = 0 hashes / 0.5 s
Using platform: NVIDIA CUDA
i 07:19:16| Full DAG loaded
Using device: GeForce GTX 970(OpenCL 1.2 CUDA)
miner 07:19:16|main Mining on PoWhash #3a12900e : 0 H/s = 0 hashes / 0.831 s
Printing program log
Creating one big buffer for the DAG
Loading single big chunk kernels
Mapping one big chunk.
miner 07:19:17|main Mining on PoWhash #3a12900e : 0 H/s = 0 hashes / 0.811 s
Creating buffer for header.
Creating mining buffer 0
Creating mining buffer 1
miner 07:19:18|main Mining on PoWhash #3a12900e : 3898052 H/s = 3145728 hashes / 0.807 s
miner 07:19:19|main Mining on PoWhash #3a12900e : 7757652 H/s = 6291456 hashes / 0.811 s
miner 07:19:20|main Mining on PoWhash #3a12900e : 7182027 H/s = 6291456 hashes / 0.876 s
miner 07:19:21|main Mining on PoWhash #3a12900e : 7767229 H/s = 6291456 hashes / 0.81 s
miner 07:19:21|main Mining on PoWhash #3a12900e : 7815473 H/s = 6291456 hashes / 0.805 s
miner 07:19:22|main Mining on PoWhash #3a12900e : 7757652 H/s = 6291456 hashes / 0.811 s
miner 07:19:23|main Mining on PoWhash #3a12900e : 6504813 H/s = 5242880 hashes / 0.806 s
miner 07:19:24|main Mining on PoWhash #3a12900e : 7607564 H/s = 6291456 hashes / 0.827 s
miner 07:19:25|main Mining on PoWhash #3a12900e : 7719577 H/s = 6291456 hashes / 0.815 s
Same weirdness as with the official version -- it benches at about 18 MH/s but running for real only manages what you see above, about 7.7 MH/s. At least the inconsistency is consistent between the two versions, though!
Yeah there's an alternating hashrate for both my GPUs one in Win 7 one on Win 10.
My 970 used to be on Win10 till I moved it to the win 7 pc. It ran at around 7.7 too. Now my 280x runs at 13.2 on the win 10 when it's supposed to be getting 22. Though the bench shows 15 for some odd reason on win 10
Thanks for the cleanup! Since a GTX 660 supports Compute 3.0, I guess I will give this (old) branch a shot. Does it still work? You mentioned that it needs to be patched up...
It should still work. The build command is slightly different though:
cmake -DETHASHCU=1 instead of cmake -DBUNDLE=cudaminer
Also the cmd line switches are different. Just check with ethminer --help. If you're on Windows, I remember I did build it sometime ago for somebody. I'll see if I can find it.
The 0.9.41-genoil-1.0.1 seems to work on Windows 10 on my 970:
...
Same weirdness as with the official version -- it benches at about 18 MH/s but running for real only manages what you see above, about 7.7 MH/s. At least the inconsistency is consistent between the two versions, though!
This is known behaviour. It is not caused by a bug in ethminer. It is caused by a different way of handling GPU virtual memory addressing in Windows 10, leading to TLB trashing. I cannot work around it. The only hope is Nvidia/Microsoft. NVidia apparently is aware of the issue. AMD cards suffer from the same issue.
The 0.9.41-genoil-1.0.1 seems to work on Windows 10 on my 970:
...
Same weirdness as with the official version -- it benches at about 18 MH/s but running for real only manages what you see above, about 7.7 MH/s. At least the inconsistency is consistent between the two versions, though!
This is known behaviour. It is not caused by a bug in ethminer. It is caused by a different way of handling GPU virtual memory addressing in Windows 10, leading to TLB trashing. I cannot work around it. The only hope is Nvidia/Microsoft. NVidia apparently is aware of the issue. AMD cards suffer from the same issue.
Thanks for the explanation. Finally understand . So we can only hope that AMD and NVidia comes out with a new driver optimised for Windows 10
The 0.9.41-genoil-1.0.1 seems to work on Windows 10 on my 970:
...
Same weirdness as with the official version -- it benches at about 18 MH/s but running for real only manages what you see above, about 7.7 MH/s. At least the inconsistency is consistent between the two versions, though!
This is known behaviour. It is not caused by a bug in ethminer. It is caused by a different way of handling GPU virtual memory addressing in Windows 10, leading to TLB trashing. I cannot work around it. The only hope is Nvidia/Microsoft. NVidia apparently is aware of the issue. AMD cards suffer from the same issue.
Thanks for the explanation. Finally understand . So we can only hope that AMD and NVidia comes out with a new driver optimised for Windows 10
It should still work. The build command is slightly different though:
cmake -DETHASHCU=1 instead of cmake -DBUNDLE=cudaminer
Also the cmd line switches are different. Just check with ethminer --help. If you're on Windows, I remember I did build it sometime ago for somebody. I'll see if I can find it.
I run Arch Linux and never use Windows Building fails unfortunately, I opened an issue on github.
@Genoil Sorry to ask a newb question, but what compiler/make system do I need to compile this?
I'm considering hacking the source to attempt to run at less than 100% GPU usage, because my system runs very sluggishly when it's mining. I'm thinking about deliberately reducing workload by (say) figuring out that 7.7 MH/s is my card's speed but then throttling to 90% of that hashrate. I figure I could then run the mining on a non-dedicated machine while I still use it for other stuff.
ethash_cuda_miner::search() looks like a potential candidate for introducing the throttling, but I admit I'm clueless as to how CUDA really works and what might usefully limit GPU utilization.
Try lowering --cuda-gridsize first. At some point the GPU won't be able to reach full saturation so hash rate should drop.
I just use MSVC 2013. You can use the free version but for CUDA debugging Pro is recommended. ATM the build environment generated by cmake is a bit botched on Windows. But if you manage to come that far, I'll help you
The 0.9.41-genoil-1.0.1 seems to work on Windows 10 on my 970:
...
Same weirdness as with the official version -- it benches at about 18 MH/s but running for real only manages what you see above, about 7.7 MH/s. At least the inconsistency is consistent between the two versions, though!
This is known behaviour. It is not caused by a bug in ethminer. It is caused by a different way of handling GPU virtual memory addressing in Windows 10, leading to TLB trashing. I cannot work around it. The only hope is Nvidia/Microsoft. NVidia apparently is aware of the issue. AMD cards suffer from the same issue.
Thanks for the explanation. Finally understand . So we can only hope that AMD and NVidia comes out with a new driver optimised for Windows 10
But I can't really figure out what size it uses currently..
AH that's great. So they're working on it. Hopefully it will be released soon as Homestead is on its way. Also I wish you the best of luck in your work with the developers. Still waiting for my first ETH in the new wallet and hopefully I'll be able to send it out
@syaoran99 there's no indication anyone is working on anything to fix it.
Oh ok, that sucks I misunderstood then. I guess it's double boot sequence for my other pc with windows 10 until it is fixed or mining is over lol
Thanks again Genoil. I'll try to figure out how to unlock my geth account first. Somehow I can't unlock it to send Ether even when I created new accounts.
@syaoran99 there's no indication anyone is working on anything to fix it.
Oh ok, that sucks I misunderstood then. I guess it's double boot sequence for my other pc with windows 10 until it is fixed or mining is over lol
Thanks again Genoil. I'll try to figure out how to unlock my geth account first. Somehow I can't unlock it to send Ether even when I created new accounts.
The only hope is that NVIDIA take it seriously if it also affects more serious GPGPU stuff like deep learning or what not, which I think is true.
@syaoran99 there's no indication anyone is working on anything to fix it.
Oh ok, that sucks I misunderstood then. I guess it's double boot sequence for my other pc with windows 10 until it is fixed or mining is over lol
Thanks again Genoil. I'll try to figure out how to unlock my geth account first. Somehow I can't unlock it to send Ether even when I created new accounts.
The only hope is that NVIDIA take it seriously if it also affects more serious GPGPU stuff like deep learning or what not, which I think is true.
What about AMD lol they would need to rectify it too because they're also affected by it. I knew I shouldn't have gone with windows 10. It's still buggy
Either way, nothing we can do for now. But if there's any way I can assist you do let me know. I'll see what I can do
Try lowering --cuda-gridsize first. At some point the GPU won't be able to reach full saturation so hash rate should drop.
Thanks for the info. I'm now using --cuda-gridsize 128 and the CPU is running at about 97% utilization, about 6.9 Mh/s instead of 7.7, but the machine is totally responsive and usable. Win!
Try lowering --cuda-gridsize first. At some point the GPU won't be able to reach full saturation so hash rate should drop.
Thanks for the info. I'm now using --cuda-gridsize 128 and the CPU is running at about 97% utilization, about 6.9 Mh/s instead of 7.7, but the machine is totally responsive and usable. Win!
Try lowering --cuda-gridsize first. At some point the GPU won't be able to reach full saturation so hash rate should drop.
Thanks for the info. I'm now using --cuda-gridsize 128 and the CPU is running at about 97% utilization, about 6.9 Mh/s instead of 7.7, but the machine is totally responsive and usable. Win!
i'm using this parameter if i want to watch video or do something in my pc while mining.
--cuda-extragpu-mem 512 (512 = 512 Mb, my card is GTX 970. 3.5 Gb is enough for mining ether).
and.... go buy another HDD and install it with Windows 7. 2 days ago i get the same result as you, my 970 only get 7 mH/s in Windows 10 x64. i install Windows 7 on my other HDD, now it mine @ 18.5 mH/s. pretty happy with the result
@Genoil say I have both AMD and NVIDIA cards in the same Windows PC. I can't use one instance of ethminer to mine on both. Therefore I have to run two instances of ethminer. But this is not possible within the same user account, since both ethminers are trying to access the same DAG file. Any workaround? Or you would have to add some patch to specify DAG file folder location (which would be usefull anyway)? Thanks!
@Genoil say I have both AMD and NVIDIA cards in the same Windows PC. I can't use one instance of ethminer to mine on both. Therefore I have to run two instances of ethminer. But this is not possible within the same user account, since both ethminers are trying to access the same DAG file. Any workaround? Or you would have to add some patch to specify DAG file folder location (which would be usefull anyway)? Thanks!
@kenshirothefist I'm trying to figure out a way to have both of them on the same PC as well. Do you have any idea how to change the directory of the second ethminer instance?
That was what @Genoil suggested however I am pretty bad with it so I have no idea what the actual code is supposed to be and what steps I am supposed to take to change the directory for the second instance of ethminer so that they will be using two different DAG files.
Comments
I'm now having problems with even getting the R9 280x to run on this windows 10 and can't seem to get it to even get ethminer to stay open. After opening it it just pops close in some instances, while others run for a but then crashes showing DAG generation failed.
Anyone know what's happening?
Building fails for me:
I know this is related to the DAG size and Win10 being demanding for the space, but is there a workaround it?
I've done a bit of cleaning up on the repo. There are just two branches left:
master. Targetted mainly at Compute 3.5 and up. There's a new Win64 binary at https://github.com/Genoil/cpp-ethereum/blob/master/releases/ethminer-0.9.41-genoil-1.0.1.zip. I have just witnessed it submit a share on a GTX960. Please test on other 9x0.
compute30. It is a rather old branch and needs to be patched up with the cuda scheduling stuff. But it is the best performing branch on Compute 3.0 devices because it user uint64 instead of uint2 for holding the state.
I've copied your stuff and pasted in the folder which I'm usually farming on, replacing all the files that you've provided that is duplicate with the old ones. (Not sure if that works)
I've then tried running the ethminer pooled to dwarfpool and it is submitting shares. That was on my GTX970 on Windows 7 64bit running on 8GB ram.
I'm not sure if the speed is faster though because the hashrate keeps alternating between 14mhs and 19mhs using your updated files.
I've also tried it out on the R9 280x on the windows 10 computer but it did not speed up nor fix the issue with the card running slow on Windows 10 similar to the 970 last time when it was on this windows 10 too. Also the R9 280x seems to be experiencing an alternating hashrate just like the 970 between 11mhs and 15mhs this time using your new files.
Hope this helps. Also hopefully there's a workaround windows 10
Thanks for the cleanup! Since a GTX 660 supports Compute 3.0, I guess I will give this (old) branch a shot. Does it still work? You mentioned that it needs to be patched up...
My 970 used to be on Win10 till I moved it to the win 7 pc. It ran at around 7.7 too. Now my 280x runs at 13.2
cmake -DETHASHCU=1 instead of cmake -DBUNDLE=cudaminer
Also the cmd line switches are different. Just check with ethminer --help. If you're on Windows, I remember I did build it sometime ago for somebody. I'll see if I can find it.
https://msdn.microsoft.com/en-us/library/windows/hardware/dn894180(v=vs.85).aspx
But I can't really figure out what size it uses currently..
Thank you, your release 1.0.1 fixed the "no share issue". (GTX 970)
Building fails unfortunately, I opened an issue on github.
I'm considering hacking the source to attempt to run at less than 100% GPU usage, because my system runs very sluggishly when it's mining. I'm thinking about deliberately reducing workload by (say) figuring out that 7.7 MH/s is my card's speed but then throttling to 90% of that hashrate. I figure I could then run the mining on a non-dedicated machine while I still use it for other stuff.
ethash_cuda_miner::search() looks like a potential candidate for introducing the throttling, but I admit I'm clueless as to how CUDA really works and what might usefully limit GPU utilization.
I just use MSVC 2013. You can use the free version but for CUDA debugging Pro is recommended. ATM the build environment generated by cmake is a bit botched on Windows. But if you manage to come that far, I'll help you
Thanks again Genoil. I'll try to figure out how to unlock my geth account first. Somehow I can't unlock it to send Ether even when I created new accounts.
Either way, nothing we can do for now. But if there's any way I can assist you do let me know. I'll see what I can do
--cuda-extragpu-mem 512 (512 = 512 Mb, my card is GTX 970. 3.5 Gb is enough for mining ether).
this is my full setup:
ethminer --cuda-grid-size 2048 --cuda-block-size 128 --cuda-extragpu-mem 512 -U -F NAME_OF_POOL
and.... go buy another HDD and install it with Windows 7. 2 days ago i get the same result as you, my 970 only get 7 mH/s in Windows 10 x64. i install Windows 7 on my other HDD, now it mine @ 18.5 mH/s. pretty happy with the result
That was what @Genoil suggested however I am pretty bad with it so I have no idea what the actual code is supposed to be and what steps I am supposed to take to change the directory for the second instance of ethminer so that they will be using two different DAG files.