112 kH/s on a GTX 660 (autoconf 75x4 or 150x2)
Topic: [ANN] cudaMiner & ccMiner CUDA based mining applications [Windows/Linux/MacOSX] - page 1125. (Read 3426947 times)
April 13, 2013, 10:05:16 PM
April 13, 2013, 08:47:15 PM
I get 130KHash/sec with my GTX 560Ti with the 14th April build. I can now run a CPU miner with 7 threads too, rather than just 6, for a total of 171KHash/sec.
For me, quitting seems a bit more reliable on this version, sort of. When I run it under the debugger and press Ctrl+C, it now crashes in the console control handler, rather than killing the driver
(I haven't investigated more deeply yet.)
--Tom
For me, quitting seems a bit more reliable on this version, sort of. When I run it under the debugger and press Ctrl+C, it now crashes in the console control handler, rather than killing the driver
(I haven't investigated more deeply yet.)
--Tom
April 13, 2013, 07:41:55 PM
Downloaded and testing now.
First thing I noticed with my gtx560se's is a higher hashrate than before using the same config.
4/13/2013
gtx560se
config: 24x4
105-107kh/s
4/14/2013
gtx560se
config: 24x4
109kh/s
EDIT:
Seems that now when I try to exit it, it reboots the computer (not a huge deal really).
First thing I noticed with my gtx560se's is a higher hashrate than before using the same config.
4/13/2013
gtx560se
config: 24x4
105-107kh/s
4/14/2013
gtx560se
config: 24x4
109kh/s
EDIT:
Seems that now when I try to exit it, it reboots the computer (not a huge deal really).
April 13, 2013, 07:18:14 PM
I posted the April 14 version, which lowers CPU use a lot (especially for high kHash values).
The one notable exception is on Linux with the -i 1 flag (interactive). Then somehow it pegs a CPU core - for me on Ubuntu 12.4 at least. Something funky going on there which I have yet to figure out.
April 13, 2013, 06:58:14 PM
Has anyone successfully to connected to the weminteltc.com pool?
Their stratum server listed on their site is stratum+tcp://eu.wemineltc.com:3333
i.e. http://www.wemineltc.com/gettingstarted
I also tried just http://eu.wemineltc.com:3333
I get connection errors for both.
I downloaded their stratum proxy executable, it connects, but only solo mines packets.
Not sure what I need to populate for the connection address at this point.
Nice coding. Speed improvement is great. Went from from 83kHs (cgminer) to 148kHs (64x2 on a GTX560ti)
--edit--
Solution: (Thanks again Baesik!)
I'm mining on wemineltc.com with cudaminer right now. I'm pretty new at all this so took me a while to get it working.
You need to use the stratum proxy and launch it with these parameters
-pa scrypt -o eu.wemineltc.com -p 3333
You can just right click on stratum_proxy.exe and create a shortcut. Right click the shortcut and open properties and paste those settings at the end of the target box.
Do the same thing with cudaminer but paste these settings
-o 127.0.0.1:8332 -O username:password -a scrypt
Remember, the username has to be the miner name you setup on wemineltc.com
You just need to launch the proxy first and then cudaminer, both with the shortcuts you made.
Their stratum server listed on their site is stratum+tcp://eu.wemineltc.com:3333
i.e. http://www.wemineltc.com/gettingstarted
I also tried just http://eu.wemineltc.com:3333
I get connection errors for both.
I downloaded their stratum proxy executable, it connects, but only solo mines packets.
Not sure what I need to populate for the connection address at this point.
Nice coding. Speed improvement is great. Went from from 83kHs (cgminer) to 148kHs (64x2 on a GTX560ti)
--edit--
Solution: (Thanks again Baesik!)
I'm mining on wemineltc.com with cudaminer right now. I'm pretty new at all this so took me a while to get it working.
You need to use the stratum proxy and launch it with these parameters
-pa scrypt -o eu.wemineltc.com -p 3333
You can just right click on stratum_proxy.exe and create a shortcut. Right click the shortcut and open properties and paste those settings at the end of the target box.
Do the same thing with cudaminer but paste these settings
-o 127.0.0.1:8332 -O username:password -a scrypt
Remember, the username has to be the miner name you setup on wemineltc.com
You just need to launch the proxy first and then cudaminer, both with the shortcuts you made.
April 13, 2013, 04:28:49 PM
Guess thats good know that I'm just finding out the behavior of the card more. Is there any reason the titan can't benefit from the advances for the other kernels though? Shouldn't it be using the best kernel not compiled for compute 3.5 until it is understood why the nvcc compiler seems to break 3.5?
If I don't compile for compute 3.5, you don't get to use the funnel shifter. If I add my memory optimizations into compute 3.5 code, you get a crash. I think the funnel shifter may outweigh the memory optimization benefits.
Oh, and by the way I have a windows build that runs on 1/4 the CPU load it used before.
Christian
Great work
I'll be sure to throw a few more coins your way. If I could i'd just permanantly donate a few percent of my earnings April 13, 2013, 04:23:22 PM
Guess thats good know that I'm just finding out the behavior of the card more. Is there any reason the titan can't benefit from the advances for the other kernels though? Shouldn't it be using the best kernel not compiled for compute 3.5 until it is understood why the nvcc compiler seems to break 3.5?
If I don't compile for compute 3.5, you don't get to use the funnel shifter. If I add my memory optimizations into compute 3.5 code, you get a crash. I think the funnel shifter may outweigh the memory optimization benefits.
Oh, and by the way I have a windows build that runs on 1/4 the CPU load it used before. UPDATE: I am crunching with 207 kHash/s on 2 GPUs, and the CPU is nearly idling at 6%. How cool is that?
Christian
April 13, 2013, 02:16:29 PM
works great on my gtx460m averaging 45khash
-l 64x4, -l 160x2, -l 96x2 all give me about the same khash
haven't really seen any noticeable improvement in khash between v10 and v13. But the -i feature is great addition. Would be nice to have an easy let down option. Driver crashes with cntrl c. It always recovers in a few seconds though so no big deal.
Great work, thank you very much. Will definitely be getting a donation from me once I have coins.
-l 64x4, -l 160x2, -l 96x2 all give me about the same khash
haven't really seen any noticeable improvement in khash between v10 and v13. But the -i feature is great addition. Would be nice to have an easy let down option. Driver crashes with cntrl c. It always recovers in a few seconds though so no big deal.
Great work, thank you very much. Will definitely be getting a donation from me once I have coins.
April 13, 2013, 12:11:41 PM
Using a titan with texture cache enabled it seems to be performing with more luck.
Except that the Titan kernel is exactly identical to the 04/09 version.
so enabling the texture cache can't do any harm - because the code isn't included. That's a good thing, I guess..Guess thats good know that I'm just finding out the behavior of the card more. Is there any reason the titan can't benefit from the advances for the other kernels though? Shouldn't it be using the best kernel not compiled for compute 3.5 until it is understood why the nvcc compiler seems to break 3.5?
April 13, 2013, 12:04:26 PM
I will try to reduce the CPU load by factor 4 next. It's just not cool that the CPU is loaded 30-50% when a GPU is hashing at 150 kHash/sec.
To achieve the intended reduction, I will be adding my own version of SHA256 based on compiler SSE2 intrinsics, rather than the original handwritten assembler code in the pooler-gpuminer code. I won't be putting the SHA256 onto the GPU, because that will cost you around 7-9% of performance.
As a first step I've remove all the existing leftovers from the previous SSE2 optimized code.
Christian
To achieve the intended reduction, I will be adding my own version of SHA256 based on compiler SSE2 intrinsics, rather than the original handwritten assembler code in the pooler-gpuminer code. I won't be putting the SHA256 onto the GPU, because that will cost you around 7-9% of performance.
As a first step I've remove all the existing leftovers from the previous SSE2 optimized code.
Christian
April 13, 2013, 10:37:06 AM
Using a titan with texture cache enabled it seems to be performing with more luck.
Except that the Titan kernel is exactly identical to the 04/09 version.
so enabling the texture cache can't do any harm - because the code isn't included. That's a good thing, I guess.. April 13, 2013, 10:26:24 AM
Using a titan with texture cache enabled it seems to be performing with more luck. Granted I may not understand all the metrics on P2Pool but I believe the efficiency metric guages the rate at which I share vs. the expected rate and for 2/3 of a day I've been sitting at 120% whereas with the previous 4/09 build it was a little under 100% with the same time.
My hash rate average didn't change much but the variance did. I used to be 150khash/s to 290khash/s with a mean of 22xkhash/s. The gpu has never been consistently 100% utilized and my cpu sits at about 60% utlization. My hash rates now jumps between 350khash/s and 100khash/s settling with an average of 224khash/s.
My hash rate average didn't change much but the variance did. I used to be 150khash/s to 290khash/s with a mean of 22xkhash/s. The gpu has never been consistently 100% utilized and my cpu sits at about 60% utlization. My hash rates now jumps between 350khash/s and 100khash/s settling with an average of 224khash/s.
April 13, 2013, 07:14:09 AM
The new April 13th release cleans up yesterday's mess, I hope.
The texture cache is now OFF by default and it may not even be working properly. Also the expected speed gains from the texture cache probably can't be realized because they were created by a programming error.
To make sure we are not bombing the servers with broken results, I added a CPU side validation of results. So whenever a GPU result is provably wrong, you will see a message in the log file about the result not validating on the CPU. You can still create stale results, but at least they have been computed correctly
This feature is meant to prevent me from creating another broken release because I can now easily spot when computations are wrong. It also serves as a security layer to prevent excessive overclocking from submitting computation errors as results.
The texture cache is now OFF by default and it may not even be working properly. Also the expected speed gains from the texture cache probably can't be realized because they were created by a programming error.
To make sure we are not bombing the servers with broken results, I added a CPU side validation of results. So whenever a GPU result is provably wrong, you will see a message in the log file about the result not validating on the CPU. You can still create stale results, but at least they have been computed correctly
This feature is meant to prevent me from creating another broken release because I can now easily spot when computations are wrong. It also serves as a security layer to prevent excessive overclocking from submitting computation errors as results.
April 13, 2013, 04:41:37 AM
Also, after leaving the PSU unpowered for the night, it turned back on today (whew!). Seems that it triggered some safety shutdown mechanism when I overloaded it.
The recommendation for the time being is: use the -C 0 flag, as texture caching seems broken still.
Christian
April 13, 2013, 12:12:26 AM
My 580gtx's and my 570gtx crash when i enable texture caching. Anyone able to explain this -l 30x7 thing a little bit better to me??
And how i should set up my 580gtx's ??
I'm seeing a performance boost from 12/04/2013 as well although my cards seem to be staying hotter. They would spike to 100 degrees Celsius and then fall to 70-80 but with this latest build they're staying high.
edit: wow massive improvement on my 580gtx, up from like 200 to 240 without texture caching
And how i should set up my 580gtx's ??
I'm seeing a performance boost from 12/04/2013 as well although my cards seem to be staying hotter. They would spike to 100 degrees Celsius and then fall to 70-80 but with this latest build they're staying high.
edit: wow massive improvement on my 580gtx, up from like 200 to 240 without texture caching
April 12, 2013, 10:55:44 PM
Here's a screen shot of what's happening for me right now on a Quadro 600:
http://postimg.org/image/va9l0kawx/
worst hashrate for litecoin mining so far is a 302 kh/s.
http://postimg.org/image/va9l0kawx/
worst hashrate for litecoin mining so far is a 302 kh/s.
This can't be right.
Upgrade your nVidia drivers. It seems only your CPU is doing preparatory work, and the GPU is idling. Results would not be valid and not be resulting in payouts.
Same thing happens when specifying a CUDA device with -d that doesn't exist.
Error checking is one point still on my TODO list, and I haven't really started with it yet.
I'll have to mess around with this some more to see what I can get out of it, but on a Quadro 4000 I'm testing out right now, I seem to be (accurately) averaging around around 46KH/s (still not bad, considering I had previously disqualified any Nvidia's I had access to for for mining).
I'll still stand true to my word and hit you up with as decent a donation as I can manage once I get a few coins in my pocket
First good miner program I've seen for a Nvidia card so far, so I think it's only fair. Especially if you're an IT sys admin looking to use your office's network (fulll of nvidia's and sparse on radeon's) for mining after hours... 
I have an HP Z1 with a Quadro 4000M in it, getting about 66kHash/sec out of it after autotune... if you get better results, I'd be interesting in hearing about your settings/command line options...
Actually, burnside's pool is reporting 102kH/sec out of this thing
April 12, 2013, 10:24:44 PM
yup, GT520 getting little worse results from 18 to 17.6 with texture cache on, but its getting better result than in the 10 version with texture off, 18.2, just a little.
April 12, 2013, 09:00:57 PM
I'm getting a similar result as that.
Local hashrate is awesome...but the pool isn't seeing it. I disabled the texture cache and now it's back to the pool reporting shares - but at a MUCH lower hashrate...lower than the 4/10 build. I tried to go back to the 4/10 build and was still getting a low hashrate (gtx260 only, and hashrate droped to the 40's) so I'm not sure what's going on.
Edit
I figured out what's going on. I've lost my mind. seems the only explanation. I could have swore that stupid gtx260 got a higher hashrate than 44kh/s on the 4/10 build.
4/12 build still doesn't seem to send shares when the texture cache is enabled. I'm not sure what's going on...but cudaminer says it sends them and they're accepted...I can see the same activity going on in the proxy window, yet the shares never show up on the pool. Tried 2 different pools with the same result, and 2 different machines with the same result.
Local hashrate is awesome...but the pool isn't seeing it. I disabled the texture cache and now it's back to the pool reporting shares - but at a MUCH lower hashrate...lower than the 4/10 build. I tried to go back to the 4/10 build and was still getting a low hashrate (gtx260 only, and hashrate droped to the 40's) so I'm not sure what's going on.
Edit
I figured out what's going on. I've lost my mind. seems the only explanation. I could have swore that stupid gtx260 got a higher hashrate than 44kh/s on the 4/10 build.
4/12 build still doesn't seem to send shares when the texture cache is enabled. I'm not sure what's going on...but cudaminer says it sends them and they're accepted...I can see the same activity going on in the proxy window, yet the shares never show up on the pool. Tried 2 different pools with the same result, and 2 different machines with the same result.
April 12, 2013, 08:19:03 PM
Anyone else mining on P2Pool seeing anything like what I have below or know what this means?
I get a ton of these from cudaminer. And though it's reporting hash rates around 50kh/s only a fraction of that is reported in my P2Pool stats:
The shares submitted above with hash > target are reported as accepted in cudaminer but that really doesn't seem to be the case, it seems.
Code:
2013-04-12 21:11:33.191000 Worker Lg6VGh3ebCGdcbckC3Vy8ZyfQvz5HpYxab submitted s
hare with hash > target:
2013-04-12 21:11:33.191000 Hash: cddf094a7710ced1a683024a0b2270a335c2b11c7
92794981716bbb95ecfde59
2013-04-12 21:11:33.192000 Target: 2e7ef4a6014578000000000000000000000000000
00000000000000000000
hare with hash > target:
2013-04-12 21:11:33.191000 Hash: cddf094a7710ced1a683024a0b2270a335c2b11c7
92794981716bbb95ecfde59
2013-04-12 21:11:33.192000 Target: 2e7ef4a6014578000000000000000000000000000
00000000000000000000
I get a ton of these from cudaminer. And though it's reporting hash rates around 50kh/s only a fraction of that is reported in my P2Pool stats:
Code:
Local rate: 18.2kH/s (7.9% DOA) Expected time to share: 43.1 hours
(I also have a cpuminer on this same local node with about 16.5kh/s, so it really is next to nothing from cudaminer.)The shares submitted above with hash > target are reported as accepted in cudaminer but that really doesn't seem to be the case, it seems.
April 12, 2013, 08:16:03 PM
Going back I remember that the first tests gave me a 10% of "boo!" (not valid) on the pool.
Moving on with Stratum the rate dropped at about 2%
I'll try the new release during the nest days, by now the pc is inside his "crate"
Moving on with Stratum the rate dropped at about 2%
I'll try the new release during the nest days, by now the pc is inside his "crate"
Jump to: