Topic: [ANN] ccminer 2.3 - opensource - GPL (tpruvot) - page 161. (Read 500193 times)
Yes, I will add a binary on github for SM2.1 devices and refresh the 1.5.2 with the last commits and the icon
lyra2 works on SM2.1 (tested on a GTX460), but you need to recompile it yourself
on linux its in Makefile.am :
nvcc_ARCH = -gencode=arch=compute_20,code=\"sm_21,compute_20\"
on windows, its in Project settings (x86 Release target, CUDA C/C++ options, Code generation : compute_20,sm_21 )
blake also :
i had to underclock a bit... my GTX460 is fully broken, was 430/500 kH/s for lyra2 with a normal clock
on linux its in Makefile.am :
nvcc_ARCH = -gencode=arch=compute_20,code=\"sm_21,compute_20\"
on windows, its in Project settings (x86 Release target, CUDA C/C++ options, Code generation : compute_20,sm_21 )
Code:
[2015-02-10 17:45:23] 1 miner thread started, using 'lyra2' algorithm.
[2015-02-10 17:45:23] Stratum difficulty set to 0.1
[2015-02-10 17:45:25] accepted: 1/1 (100.00%), 279.04 khash/s yay!!!
[2015-02-10 17:45:32] GPU #0: GeForce GTX 460, 284.38 kH/s
[2015-02-10 17:45:32] accepted: 2/2 (100.00%), 284.38 khash/s yay!!!
blake also :
Code:
[2015-02-10 17:53:21] 1 miner thread started, using 'blake' algorithm.
[2015-02-10 17:53:21] Stratum difficulty set to 1
[2015-02-10 17:53:32] accepted: 1/1 (100.00%), 88782 khash/s yay!!!
i had to underclock a bit... my GTX460 is fully broken, was 430/500 kH/s for lyra2 with a normal clock
Can you compile it for me epsylon3? İf ı earn some vtc ı will donate you
The problem with compute 2.1 compability is the algorithms who use the __SHFL instruction.
For x11 compabillity (killer) Groestl and simd needs to be rewritten, and then alot of the speed increase is gone.
For x11 compabillity (killer) Groestl and simd needs to be rewritten, and then alot of the speed increase is gone.
lyra2 works on SM2.1 (tested on a GTX460), but you need to recompile it yourself
on linux its in Makefile.am :
nvcc_ARCH = -gencode=arch=compute_20,code=\"sm_21,compute_20\"
on windows, its in Project settings (x86 Release target, CUDA C/C++ options, Code generation : compute_20,sm_21 )
blake also :
i had to underclock a bit... my GTX460 is fully broken, was 430/500 kH/s for lyra2 with a normal clock
on linux its in Makefile.am :
nvcc_ARCH = -gencode=arch=compute_20,code=\"sm_21,compute_20\"
on windows, its in Project settings (x86 Release target, CUDA C/C++ options, Code generation : compute_20,sm_21 )
Code:
[2015-02-10 17:45:23] 1 miner thread started, using 'lyra2' algorithm.
[2015-02-10 17:45:23] Stratum difficulty set to 0.1
[2015-02-10 17:45:25] accepted: 1/1 (100.00%), 279.04 khash/s yay!!!
[2015-02-10 17:45:32] GPU #0: GeForce GTX 460, 284.38 kH/s
[2015-02-10 17:45:32] accepted: 2/2 (100.00%), 284.38 khash/s yay!!!
blake also :
Code:
[2015-02-10 17:53:21] 1 miner thread started, using 'blake' algorithm.
[2015-02-10 17:53:21] Stratum difficulty set to 1
[2015-02-10 17:53:32] accepted: 1/1 (100.00%), 88782 khash/s yay!!!
i had to underclock a bit... my GTX460 is fully broken, was 430/500 kH/s for lyra2 with a normal clock
i dont know how to compile or just know to write readline writeline commands in visualbasic
lyra2 works on SM2.1 (tested on a GTX460), but you need to recompile it yourself
on linux its in Makefile.am :
nvcc_ARCH = -gencode=arch=compute_20,code=\"sm_21,compute_20\"
on windows, its in Project settings (x86 Release target, CUDA C/C++ options, Code generation : compute_20,sm_21 )
blake also :
i had to underclock a bit... my GTX460 is fully broken, was 430/500 kH/s for lyra2 with a normal clock
on linux its in Makefile.am :
nvcc_ARCH = -gencode=arch=compute_20,code=\"sm_21,compute_20\"
on windows, its in Project settings (x86 Release target, CUDA C/C++ options, Code generation : compute_20,sm_21 )
Code:
[2015-02-10 17:45:23] 1 miner thread started, using 'lyra2' algorithm.
[2015-02-10 17:45:23] Stratum difficulty set to 0.1
[2015-02-10 17:45:25] accepted: 1/1 (100.00%), 279.04 khash/s yay!!!
[2015-02-10 17:45:32] GPU #0: GeForce GTX 460, 284.38 kH/s
[2015-02-10 17:45:32] accepted: 2/2 (100.00%), 284.38 khash/s yay!!!
blake also :
Code:
[2015-02-10 17:53:21] 1 miner thread started, using 'blake' algorithm.
[2015-02-10 17:53:21] Stratum difficulty set to 1
[2015-02-10 17:53:32] accepted: 1/1 (100.00%), 88782 khash/s yay!!!
i had to underclock a bit... my GTX460 is fully broken, was 430/500 kH/s for lyra2 with a normal clock
I can make a optimized version that supports version 2.1 with 1 BTC in donation. So start donating 
i wish to have 1 btc
but you can open thread for making it 2.1 compatible with its all optimisations so people can donate you
I can make a optimized version that supports version 2.1 with 1 BTC in donation. So start donating
should be ok on 3.0 but the binary is not made for 2.1 (i only added SM 2.1 support for one of the 2 problematic algos, from KBomba code)
will there be support for CUDA (with compute capability 2.1) ?
it already works with 2.1 AFAIK.no it doesnt work
Lyra2re;
Current implementation of x11 can't run on 2.1 nor on 3.0 devices
will there be support for CUDA (with compute capability 2.1) ?
it already works with 2.1 AFAIK.no it doesnt work
Lyra2re;
x11
will there be support for CUDA (with compute capability 2.1) ?
it already works with 2.1 AFAIK.
will there be support for CUDA (with compute capability 2.1) ?
not -d which is the device num, -f (factor) made for dev purpose (to find shares faster but which are rejected). There is no advantages except on some badly coded pools.
Algos are not all set to 1 by default, that also allow us (dev) to find the right one when we implement a new algo.
Algos are not all set to 1 by default, that also allow us (dev) to find the right one when we implement a new algo.
Thank you. I confused the JSON format "diff" for "-d" (device) commandline switch. Instead, "diff" JSON is "-f" on the commandline. I used "diff" last night as an experiment, setting ' "diff" : 0.1, ', to see if the rig would be more stable. The pool gave me a very low reported hash rate in the morning. --scryptr
not -d which is the device num, -f (factor) made for dev purpose (to find shares faster but which are rejected). There is no advantages except on some badly coded pools.
Algos are not all set to 1 by default, that also allow us (dev) to find the right one when we implement a new algo.
Algos are not all set to 1 by default, that also allow us (dev) to find the right one when we implement a new algo.
BUILD 1.5.2 Linux--
I reloaded Linux 14.04.1 on my 6 card 750ti SC rig. I was able to get a clean load, although I had wanted to move to Utopic Unicorn (14.1). The CUDA 6.5 toolkit does not support Utopic Unicorn presently, and CUDA 7.0 toolkit is pre-release.
After burning the OS, I installed CUDA 6.5, and then downloaded SP_'s v1.5.32 and tpruvot's v1.5.2 release. After compilation, I tested them. Both compiled without errors, but I noticed several warnings during the compilation of v1.5.32.
SP_'s version ran at about 35.5mh/s on my 6 card rig, but proved not to be stable. It crashed, requiring a cold boot of the rig, after 4-5 hours. Tpruvot's version is currently running at about 33.6mh/s on the same rig, and has been reliable for the last couple of days. In retrospect, I had SP_'s v31 up to 36.3mh/s on the same rig, but it was never stable for more than 2-3 hours. SP_'s v31 is currently running on my 6x750ti FTW rig at 37.8mh/s, and runs for days at a time.
With the Windows binaries, my GTX 960 gets 8.7mh/s with release 1.5.2, tpruvot. It gets 9.6mh/s with v1.5.32, SP_.
QUESTION: What are the advantages of running the "-d" switch? It divides (or multiplies) the pool-provided "diff" setting, I know, but how does that help? --scryptr
I reloaded Linux 14.04.1 on my 6 card 750ti SC rig. I was able to get a clean load, although I had wanted to move to Utopic Unicorn (14.1). The CUDA 6.5 toolkit does not support Utopic Unicorn presently, and CUDA 7.0 toolkit is pre-release.
After burning the OS, I installed CUDA 6.5, and then downloaded SP_'s v1.5.32 and tpruvot's v1.5.2 release. After compilation, I tested them. Both compiled without errors, but I noticed several warnings during the compilation of v1.5.32.
SP_'s version ran at about 35.5mh/s on my 6 card rig, but proved not to be stable. It crashed, requiring a cold boot of the rig, after 4-5 hours. Tpruvot's version is currently running at about 33.6mh/s on the same rig, and has been reliable for the last couple of days. In retrospect, I had SP_'s v31 up to 36.3mh/s on the same rig, but it was never stable for more than 2-3 hours. SP_'s v31 is currently running on my 6x750ti FTW rig at 37.8mh/s, and runs for days at a time.
With the Windows binaries, my GTX 960 gets 8.7mh/s with release 1.5.2, tpruvot. It gets 9.6mh/s with v1.5.32, SP_.
QUESTION: What are the advantages of running the "-d" switch? It divides (or multiplies) the pool-provided "diff" setting, I know, but how does that help? --scryptr
Latest 1.5.2-git --
I am running your very latest build, posted about an hour ago. It runs at 34mh/s (quark) on my 6-card, 750ti rig. That is an improvement over an earlier build of yours, 1.5.2..., that ran at 32mh/s.
However, I was getting 36mh/s on sp_'s fastest rendition, 1.5.31; unfortunately his latest builds have been unstable at times. Some won't compile on Linux. I am hoping that you may be looking at another clean-up and integration build that incorporates the best of the best.
I admire your work, it runs well. And, for a long time! Days, weeks... --scryptr
I am running your very latest build, posted about an hour ago. It runs at 34mh/s (quark) on my 6-card, 750ti rig. That is an improvement over an earlier build of yours, 1.5.2..., that ran at 32mh/s.
However, I was getting 36mh/s on sp_'s fastest rendition, 1.5.31; unfortunately his latest builds have been unstable at times. Some won't compile on Linux. I am hoping that you may be looking at another clean-up and integration build that incorporates the best of the best.
I admire your work, it runs well. And, for a long time! Days, weeks... --scryptr
hello mate
you mean unstable is "crash" ?
if thats your problem you can make batch file to restart your ccminer every x Second
In Linux, you can make a bash script, or set a cron command, or both, to do the same thing. It isn't the same as a DOS batch file run under Windows, though. A batch file can be a far simpler implementation, really.
The problem I have is that once the mining program crashes, it requires a cold boot. Further, I need to re-install Linux on my problem rig. It isn't just the mining program, my whole build is whacked. However, tpruvot's work seems to be more stable to me than sp_'s hot-rod builds. SP_ does good work, and he always finds more hash, but somehow it won't compile right just now. --scryptr
EDIT: SP_'s build 1.5.32 has been corrected by the author and now builds on Linux without further editing. --scryptr
Latest 1.5.2-git --
I am running your very latest build, posted about an hour ago. It runs at 34mh/s (quark) on my 6-card, 750ti rig. That is an improvement over an earlier build of yours, 1.5.2..., that ran at 32mh/s.
However, I was getting 36mh/s on sp_'s fastest rendition, 1.5.31; unfortunately his latest builds have been unstable at times. Some won't compile on Linux. I am hoping that you may be looking at another clean-up and integration build that incorporates the best of the best.
I admire your work, it runs well. And, for a long time! Days, weeks... --scryptr
I am running your very latest build, posted about an hour ago. It runs at 34mh/s (quark) on my 6-card, 750ti rig. That is an improvement over an earlier build of yours, 1.5.2..., that ran at 32mh/s.
However, I was getting 36mh/s on sp_'s fastest rendition, 1.5.31; unfortunately his latest builds have been unstable at times. Some won't compile on Linux. I am hoping that you may be looking at another clean-up and integration build that incorporates the best of the best.
I admire your work, it runs well. And, for a long time! Days, weeks... --scryptr
hello mate
you mean unstable is "crash" ?
if thats your problem you can make batch file to restart your ccminer every x Second
Latest 1.5.2-git --
I am running your very latest build, posted about an hour ago. It runs at 34mh/s (quark) on my 6-card, 750ti rig. That is an improvement over an earlier build of yours, 1.5.2..., that ran at 32mh/s.
However, I was getting 36mh/s on sp_'s fastest rendition, 1.5.31; unfortunately his latest builds have been unstable at times. Some won't compile on Linux. I am hoping that you may be looking at another clean-up and integration build that incorporates the best of the best.
I admire your work, it runs well. And, for a long time! Days, weeks... --scryptr
I am running your very latest build, posted about an hour ago. It runs at 34mh/s (quark) on my 6-card, 750ti rig. That is an improvement over an earlier build of yours, 1.5.2..., that ran at 32mh/s.
However, I was getting 36mh/s on sp_'s fastest rendition, 1.5.31; unfortunately his latest builds have been unstable at times. Some won't compile on Linux. I am hoping that you may be looking at another clean-up and integration build that incorporates the best of the best.
I admire your work, it runs well. And, for a long time! Days, weeks... --scryptr
Can you add in the Interactive (-i) flag that CudaMiner has? To make the miner not take up 100% of a cards performance?
-i is already there. Max range is mostly around 20 (-i 17 already gives better control over your desktop), but you can go higher. It will crash if you reach maximum
He's working on specifying it per gpu, ATM it's per ccminer process (so just run 2 ccminers, switch with -d 0 -i 17 and -d 1,2 -i 20)Also would it be possible to add in Scrypt and possibly Neoscrypt? I know Nvidia doesnt do these very well, but sometimes i mine just to heat the house at winter (many others too!)
Neoscrypt is in the works
https://bitcointalksearch.org/topic/neoscrypt-algo-for-ccminer-and-nvidia-card-call-for-donation-916336But why would you want scrypt? Need electric heating?
Thanks for a great miner, it runs my two 750ti's for weeks without hiccups.
I have suggestions:
Can you add in the Interactive (-i) flag that CudaMiner has? To make the miner not take up 100% of a cards performance?
I also have a gtx660 and it would be nice to run it from your fork so that i could work on the desktop GPU as well while it mines.
In CudaMiner you can specify e.g '-i 1 0 0' to make gpu 0 interactive, while gpu 1 and 2 run at 100%.
Also would it be possible to add in Scrypt and possibly Neoscrypt? I know Nvidia doesnt do these very well, but sometimes i mine just to heat the house at winter (many others too!)
Edit: Maybe someone could take a look at the X13 module that was added in too?
My GPU graphs in Afterburner for x13 compared to x11 shows that x13 has quite a few 'GPU Usage' dips to nearly 0% GPU. X11 is quite different. Its like the switching to/from the 2 extra algos goes wrong.
My max hash reached for x11 is 3065 and 2445 for X13. (EVGA FTW edition overclocked +31/+39/+550)
I have suggestions:
Can you add in the Interactive (-i) flag that CudaMiner has? To make the miner not take up 100% of a cards performance?
I also have a gtx660 and it would be nice to run it from your fork so that i could work on the desktop GPU as well while it mines.
In CudaMiner you can specify e.g '-i 1 0 0' to make gpu 0 interactive, while gpu 1 and 2 run at 100%.
Also would it be possible to add in Scrypt and possibly Neoscrypt? I know Nvidia doesnt do these very well, but sometimes i mine just to heat the house at winter (many others too!)
Edit: Maybe someone could take a look at the X13 module that was added in too?
My GPU graphs in Afterburner for x13 compared to x11 shows that x13 has quite a few 'GPU Usage' dips to nearly 0% GPU. X11 is quite different. Its like the switching to/from the 2 extra algos goes wrong.
My max hash reached for x11 is 3065 and 2445 for X13. (EVGA FTW edition overclocked +31/+39/+550)
Jump to: