Mining Litecoin and Alternative Cryptocurrencies - Estimated ROI

My last post on the ROI for mining Litecoin with the new R9 290/290X GPUs is still more or less on target -- difficulty is stabilizing for now, with an expected return of around 2 LTC per week per R9 GPU. That works out to around $45 per week, or $180 per month, so you'll have paid for your R9 290/290X in three months, give or take. But what about switching to some alternative cryptocurrency?

In roughly one week of mining, I mined about 1 BTC with 7000 KHash of GPUs. That works out to over $700 per week for hardware that you could match with seven or eight R9 290X GPUs, eight or nine R9 290 GPUs, or ten R9 280X GPUs. Now if you do the math, at present that means best case you would need $4600 worth of R9 290X cards, $4000 or R9 290 cards, or just $3500 worth of R9 280X (HD 7970) cards. Until prices are closer to MSRP, it looks like the 280X is the one to get.

Now, if current alternative cryptocurrency mining remains even close to where it's been, we're looking at roughly $2800 per month, so you'd pay off the GPUs in less than two months, and realistically all of the hardware could be paid for within two months. That's pretty darn appealing if you ask me! And you don't have to go out and buy dozens of cards in one fell swoop either -- just start with a single rig and if you go with 3-way R9 280X you could have the whole system for around $1500, and it would be paid for in about six weeks.

The problem is Hashco.ws is still in a state of disarray following the hack, so I've moved to Middlecoin for now. I switched about 5000 KHash of PCs to Middlecoin six hours ago, and at present it looks like my BTC balance is 0.0135 BTC. For a full day of mining that works out to 0.054 BTC, which would yield roughly $40 per day, $1200 per month -- not quite so rosy. I'll update tomorrow when I've seen just how many BTC I get through Middlecoin after a full day of mining, as it could still be ramping up my payouts; I'm hoping to get about twice that (0.1 BTC per day), which is closer to my previous rate with Hashco.ws.

Update: I've switched most of my systems back to Hashco.ws as the primary pool, with Middlecoin as the secondary pool. Hashco.ws is still a bit of a pain, as you can't log in to create new workers, and if you don't have an account already you're out of luck until they get the front end to their site working again. However, I'm getting payouts of around 0.075 BTC per day from Hashco.ws, and Middlecoin is typically providing another 0.015 BTC per day. So around 7000KHash/sec is generating 0.09 BTC daily, or close to $70 per day in income. Power costs are around $400 per month for my systems, but modern R9 builds should be more like $200-$250. Net income per month thus works out to $1500-$2250.

Flashing Radeon HD 7970 GHZ to R9 280X

I'm in perhaps a bit of an unusual situation in that I have a Radeon HD 7970 GHz Edition GPU, direct from AMD. The Vendor ID is 1002 and the Subsystem ID is 3000. The VRM on this card identifies as CHL822x and the memory is Hynix H5GQ2H24AFR. Looking through TechPowerUp's VBIOS catelog, I kept looking for VBIOS that would provided decent hashing performance from this card. Previously, I only managed to hash at around 510-520KHash/sec, which is quite low for a 7970, but the problem appears to be with most 7970 GHz Edition cards. The solution is to flash to a non-GHz Edition -- if you can!

I tried numerous VBIOS options from a variety of vendors -- ASUS, Sapphire, Gigabyte, XFX, etc. -- all to no avail. I had to force-flash most of these, due to a Subsytem ID mismatch, and not surprisingly several of the VBIOS options I tried ended up requiring me to boot up off a different GPU to recover to a working VBIOS. Up until last night, I was met with zero success -- the Sapphire VBIOS I tried flashed successfully and I could usually boot into Windows, but I would get a BSOD any time I tried to tax the GPU.

As you might guess from the title, the solution for me ended up being to flash to a Radeon R9 280X VBIOS. I still had to force flash (ATIWinFlash.exe -f -p 0 R9280X.rom), but the Vendor ID was 1002 and the Subsystem ID was 3001, so I figured I had a good chance of succeeding...and it worked! Thank goodness -- no more of this 500KHash silliness for my 7970 GHz card!

If you're having a similar problem, most likely you're in the same situation and have one of the "not very fast for scrypt" GHz Edition/Overclocked cards. You'll probably have to try more than one VBIOS before you can find one that works, but don't lose hope! Symptoms of the problem are that your 7970 will actually hash slower at intensities above 13, plus as noted the inability to break 600KHash, let alone 700KHash. Here's what I was running prior to the flash:

cgminer.exe --auto-fan --failover-only --scrypt -o stratum01.hashco.ws:8888 -u trogdorjw73.tester -p tester -I 13 --gpu-fan 40-95 --gpu-engine 1050 --gpu-memclock 1550 --gpu-vddc 1.170 --thread-concurrency 24160 -g 1 --temp-target 85 --temp-overheat 95 --temp-cutoff 100

With that configuration and the original VBIOS I was pulling 510KHash, and I really couldn't get it to run any better. With the update to an R9 280X VBIOS, I'm now pulling around 700KHash with the same settings but I 20. That makes for decent hashing but a totally useless system if you need to do anything else, but the 7970 (R9 280X) has an interesting quirk: you can often get equal or better hash rates at lower intensities with -g 2 and a lower thread concurrency. Here are my current "usable PC" settings (and note that the GPU core is now clocked at 1000MHz instead of 1050):

cgminer.exe --auto-fan --failover-only --scrypt -o stratum01.hashco.ws:8888 -u trogdorjw73.tester -p tester -I 13 --gpu-fan 40-95 --gpu-engine 1000 --gpu-memclock 1550 --gpu-vddc 1.170 --thread-concurrency 8192 -g 2 --temp-target 85 --temp-overheat 95 --temp-cutoff 100

Hopefully that will help some of you out, and if you have any of the 7970/R9 280X cards you can use similar settings to get over 700KHash. Considering a lot of R9 290 GPUs are topping out at 750-800KHash/sec (at least using their stock VBIOS), and the R9 290 cards are currently selling for over $500 (never mind the $650+ R9 290X cards!), if you can find a reasonable price on the Radeon R9 280X (some are going for $350) or one of the older Radeon HD 7970 cards (these tend to be more expensive, so look for the 280X first!) it's definitely worth considering.

Radeon R9 290/290X Litecoin Mining: New Settings and Revised Expectations

Over the past several weeks I've had a flood of comments and emails about R9 290/290X hashing performance when mining Litecoins (or any other scrypt-based cryptocurrency). Initial experience with the cards suggests that the Radeon R9 290 can hit up to 900KHash and the Radeon R9 290X can hit 1000KHash, but the key part of that is "up to". In practice, the cards vary, sometimes wildly.

There are a lot of 290X cards that seem to top out in the 800-850KHash range, and short of adding better cooling I'm not sure how much farther you can push them. R9 290 tends to be more like 750-800KHash on a lot of cards. I think if we could get voltage adjustments working, we might be able to improve on those results for a lot of cards, but we probably won't have that for a few more weeks if not months.

One of the keys to understanding what's required for tuning performance on the new Hawaii R9 290/290X cards is that AMD has built in safety protocols to keep the cards running "safely". A lot of people have tried my original settings and come up with far lower performance than expected. This is why I provided batch files to help you tune and tweak performance.

Scrypt hashing by design is far more memory intensive than SHA256 hashing. The idea was to make it impossible or at least impractical to do scrypt hashing on GPUs, let along FPGAs and ASICs. So far, no one has yet released any FPGA or ASIC hardware for scrypt devices, and I suspect we're probably still at least a year away from such hardware becoming publicly available. (There may be early hardware undergoing "testing" for month in China or elsewhere first, of course.) So when you're looking to fine-tune your GPUs, start with the memory clocks and push those as far as you can while maintaining stability -- and maybe add a few extra cooling fans to help out! If you want to hit extremely high hash rates, you'll want the memory clock at 1600MHz or higher, and most cards won't do that without some sort of additional cooling or other modification.

Once you've found the maximum reliable memory clocks for your GPUs, only then should you start tuning the GPU clock speed. What's interesting is that even though most cards will happily accept GPU engine clocks of 1000MHz or higher, in reality they'll often run at far lower clocks -- this is AMD's safety protocols kicking in. So if you start off at 950MHz core and 1350MHz RAM and a thread concurrency of 32000 (give or take), and you find your hash rates are closer to 600 or 700KHash rather than 800-900KHash, don't despair!

Start with a lower GPU clock of around 800MHz (on R9 290/290X) and then start bumping it up 25MHz after about 10 minutes or more testing at each clock speed. You'll most likely find that 850MHz ends up being the sweet spot, and then you can play with clocks a bit more bumping it up/down in 5MHz increments to see if you can squeeze a bit better performance out of your system. When all of that is done, only then should you bother with tweaking your thread concurrency.

And with that said, here are my revised settings for R9 290/290X graphics cards. I'm going to include cgminer settings for four cards as an example this time, just to illustrate what you would use. I've also included three pools, the first two being multi-coin pools, since that's what I use these days. I'm also going to try toying around with BFGminer to see if I can coax anything better out of it. For the time being, these settings are more or less "stable".

cgminer.conf settings for ~810 KHash R9 290X / ~770 KHash R9 290

{
"pools" : [
{
"url" : "http://stratum01.hashco.ws:8888",
"user" : "trogdorjw73.tester",
"pass" : "tester"
},
{
"url" : "stratum+tcp://middlecoin.com:3333",
"user" : "13saHMFfUAv1crYp3QLbFr9aP1JYnb89oh",
"pass" : "x"
},
{
"url" : "http://coinotron.com:3334",
"user" : "trogdorjw73.tester",
"pass" : "tester"
}
]
,
"intensity" : "20,20,20,20",
"worksize" : "256",
"kernel" : "scrypt",
"lookup-gap" : "2",
"thread-concurrency" : "24272,24272,24272,24272",
"gpu-engine" : "850-850,850-850,850-850,850-850",
"gpu-fan" : "45-85,45-85,45-85,45-85",
"gpu-memclock" : "1475,1475,1475,1475",
"gpu-memdiff" : "0,0,0,0",
"gpu-powertune" : "50,50,50,50",
"gpu-vddc" : "1.100,1.100,1.100,1.100",
"temp-cutoff" : "100,100,100,100",
"temp-overheat" : "95,95,95,95",
"temp-target" : "85,85,85,85",
"api-mcast-port" : "4028",
"api-port" : "4028",
"auto-fan" : true,
"expiry" : "120",
"failover-only" : true,
"gpu-dyninterval" : "7",
"gpu-platform" : "1",
"gpu-threads" : "1",
"hotplug" : "5",
"log" : "5",
"no-pool-disable" : true,
"queue" : "1",
"scan-time" : "60",
"scrypt" : true,
"temp-hysteresis" : "3",
"shares" : "0",
"kernel-path" : "/usr/local/bin"
}

And just in case this isn't clear, with the above settings you would launch cgminer.exe with the following command:

cgminer.exe --auto-fan --config cgminer.conf --failover-only

Avoiding the CGminer BSOD/Crash on Exit for R9 290/290X

One of the major annoyances with mining via cgminer on R9 290/290X hardware is that it will hard crash your system when you exit "gracefully" -- by pressing "Q" or "CTRL+C". Some people will tell you that the problem is your clock speeds, or that you're using unstable settings, but this is absolutely false. The reality is that the crash is caused by outdated code in cgminer.

You see, cgminer's developer has decided to stop supporting GPUs. I don't blame him -- he's probably earning a ton of money working on developing and maintaining his program for ASICs, and since he's only one man he can't really keep doing both. But it means that code that worked fine in the past may now have difficulties. And that's exactly what's happening.

With their Hawaii architecture, AMD updated some things for the R9 290/290X. Specifically, they've updated their Overdrive engine from version 5 to 6, which helps with things like preventing the GPUs from frying if you run them too hard. This is part of the reason why you need to carefully tune your mining rigs for each GPU -- one R9 290X may run great at 975/1550 clocks while another will totally fail at those speeds. You can often see that you've pushed the GPU engine clocks too far by watching the clocks in MSI Afterburner; if you've set the engine for 950MHz and it's bouncing around between 800-950MHz, AMD's hardware is doing its job and dropping clocks to reduce power draw and protect the chips. Drop the engine clocks 25MHz (or 50, 75, etc. MHZ) and see if clocks go up. But I digress....

So the problem with R9 290/290X (Hawaii) and BSOD/crash on exit is that cgminer is tying into older software/hardware paths that don't behave quite the same on the latest GPUs. When you exit normally and cgminer tries to release things, there's a glitch and a BSOD is the result. Note that this happens on Windows as well as Linux (though without the BSOD on Linux, obviously), so it's not just an OS problem. But what's the solution?

Update: Forget everything below this point! There's a recompiled version of cgminer available that fixes the problem, and I recommend using it.


[Old text follows so you can see how things have developed.]

Simple: don't use any of cgminer's GPU overclocking and/or temperature monitoring features. That means you have to avoid the following (as far as I can tell):

• auto-fan
• gpu-engine
• gpu-fan
• gpu-memclock
• gpu-powertune
• gpu-vddc
• temp-cutoff
• temp-overheat
• temp-target

Okay, those are easy enough to remove, but there's a problem: without tuning your GPUs, performance, hash rates, temperatures, and stability are all compromised. Yuck. The temperature targets in particular are important, as if you leave AMD's drivers to manage everything you'll have severe throttling. So you need to turn to other utilities to manage temperatures and clocks as best you can...or just live with the inability to do a normal exit from cgminer.

For what it's worth, I'm still using cgminer to control things. I tried playing with MSI Afterburner to get things to work "properly", but getting everything to persist between reboots isn't something I've fully figured out yet. When I do, I'll post instructions.

Finding Optimal Clock Speed for CGMiner and R9 290/R9 290X

Update, 12/12/2013: There were some bugs in the batch files (an errant "--" in one, for example), so I've updated them with new versions that should run properly now.

Going along with the previous post on finding the best Thread Concurrency setting for your hardware, you'll probably first want to find some good clock speeds. Unlike searching for a good TC value, tuning your clock speeds could very well lead to a system crash/hang and/or BSOD. Ideally, your system will automatically reboot, but in some cases it will get stuck and you'll have to manually intervene. Once again, I've created a couple batch files (that build off the previous batch files) for helping you find optimal values for your hardware, which you can download here. The contents of the two batch files are included below for reference:

engine-clock-test-r9version.bat:

@echo off
set threadconcurrency=24000
set gpuclock=800
set memclock=1300
set gpufan=50-75
set gpuvolt=1.100
set gpupowertune=50
set gpustopclock=1100

if exist currentgpuclock.txt (
  for /F %%x in (currentgpuclock.txt) do set gpuclock=%%x
)

setlocal EnableExtensions

:startloop
echo Current GPU Clock is %gpuclock%
echo %gpuclock%> currentgpuclock.txt
start "MinerThread" miner-tc-r9version.bat %threadconcurrency% %gpuclock% %memclock% %gpufan% %gpuvolt% %gpupowertune%
sleep 300
taskkill /im cgminer.exe /f
<nul set /p =GPU Clock %gpuclock%: >> AvgHashrateGPU.txt
grep -i "(avg)" %threadconcurrency%.txt | tail -1 >> AvgHashrateGPU.txt
set /a gpuclock=gpuclock+5
if "%gpuclock%" GTR "%gpustopclock%" goto :EOF

goto :startloop


memory-clock-test-r9version.bat:

@echo off
set threadconcurrency=24000
set gpuclock=800
set memclock=1200
set gpufan=50-75
set gpuvolt=1.100
set gpupowertune=50
set memstopclock=1700

if exist currentmemclock.txt (
  for /F %%x in (currentmemclock.txt) do set memclock=%%x
)

setlocal EnableExtensions

:startloop
echo Current RAM Clock is %memclock%
echo %memclock%> currentmemclock.txt
start "MinerThread" miner-tc-r9version.bat %threadconcurrency% %gpuclock% %memclock% %gpufan% %gpuvolt% %gpupowertune%
sleep 300
taskkill /im cgminer.exe /f
<nul set /p =RAM Clock %memclock%: >> AvgHashrateRAM.txt
grep -i "(avg)" %threadconcurrency%.txt | tail -1 >> AvgHashrateRAM.txt
set /a memclock=memclock+10
if "%memclock%" GTR "%memstopclock%" goto :EOF

goto :startloop


Other than modifying the GPU Engine or GPU Memory clock each iteration, the two files are the same. They also use the same miner-tc-r9version.bat file as before (which I didn't rename because why bother). If you create a link to the batch file you're testing and put that in your Startup folder, the batch files will also continue from where they left off in the case of a system reboot...which means if your system is unstable before the stopping clock you specify, it will be stuck in a reboot loop, so keep an eye on things or don't put the files in the Startup folder and instead save that for a stable cgminer configuration -- and be sure to set the gpustopclock and memstopclock to appropriate values.

My recommendation would be to choose a reasonable starting memory clock (around 1300 is usually safe on all R9 290/290X GPUs) and run the engine-clock-test-r9version batch file. When that finishes (or reaches a point where it cannot continue), look at the AvgHashrateGPU.txt file and you should end up with one of to things. Eiher you find out how far you can push clocks before becoming unstable and crashing (with each increase in clock speed bringing improved performance), and in that case I'd probably back off 10-25MHz from the point where the GPU crashed, but you can do as you please. The other possibility is that you'll find hash rates peak at a lower clock speed (say, 825-850MHz), and as you try going higher the AMD GPU will begin to throttle automatically. If this is happening, use the clock speed that gives you the highest hash rate.

Once you've found a good GPU clock, set the gpuclock=800 line in the second batch file, memory-clock-test-r9version, to that clock speed and then run the second script. It will do the same thing as before, except now RAM clocks go up 10MHz every five minutes until you reach the stopping clock speed (1700MHz is what I put in) or you crash -- and a crash is far more likely if you try for 1700MHz GDDR5! Check your AvgHashrateRAM.txt file for the best result and use that for your GPU, and then go run the Thread Concurrency optimization batch file and find the best TC for your system.

Here's the tricky part: you need to do the above for each and every GPU in your system(s) if you want to get optimal performance, while means you also need to tweak the miner-tc-r9version.bat file and add "--device [Number]" to the cgminer.exe command for each GPU. You might not need to do this for Thread Concurrency, but for the Engine and RAM GPU clocks it will definitely help out! Also, once you find values for each GPU that work well, you may find that running all your GPUs at once will require slightly lower clocks in order to be stable (which potentially could mean you need to check TC again, though that's probably overkill).

Now all we need is for more R9 GPUs to be available at reasonable prices -- I'm seeing prices of $700 for R9 290 and $830 for R9 290X right now! And Newegg isn't really any better last I checked (well, maybe a bit better, but still price gouging). If you've already got yourself some shiny R9 290 GPUs, happy mining while everyone else is stuck waiting!

Donations and referrals gladly accepted if this helps you out:
LTC: LXpEZcNJtikd263z7Ha3vrdYDcLU7hiKWv

CGMiner Optimal Thread Concurrency for R9 290/290X

Continuing from my previous post, I've now created a batch file to help find the optimal Thread Concurrency setting for R9 290/290X systems. The difficulty with doing this stems from the fact that normally exiting CGMiner on Windows with the new GPUs will cause a BSOD on most (all?) systems, so you can't use my other batch files. They work great on HD 7970/R9 280X and earlier systems, though, and last night I managed to increase my HD 7950 test system by 20KHash/sec per GPU. So how do we deal with R9 290/290X? We tweak things a bit and end up with some new batch files, which you can download via my Dropbox.

Instructions:

Extract the contents of that Zip file to your CGMiner folder (Windows only right now). There are five files inside, including three EXE files, but nothing dangerous; here's the quick summary of the EXE files.

Sleep.exe is a program that can be used in batch files to pause for a set amount of time (e.g. 300 seconds = "sleep 300").

Grep.exe is a common Unix program that allows you to search through files for matching strings; you can use "find" on Windows, but the output of CGMiner messes find up because it includes special characters.

Tail.exe is the last executable and it's also a port from Unix; it allows you to output the last few lines from a file (or a command); so "tail -1" gives the last line from a file or command.

I use the above three files in the batch files to help with creating a useful summary of the mining results for each thread concurrency. The two batch files are similar to before, but with some tweaks. Here's what they contain if you don't want to download:

thread-concurrency-test-r9version.bat

@echo off
set threadconcurrency=18000
set gpuclock=900
set memclock=1400
set gpufan=50-75
set gpuvolt=1.100
set gpupowertune=50

if exist currenttc.txt (
  for /F %%x in (currenttc.txt) do set threadconcurrency=%%x
)

:startloop
echo Current TC is %threadconcurrency%
echo %threadconcurrency%> currenttc.txt
start "MinerThread" miner-tc-r9version.bat %threadconcurrency% %gpuclock% %memclock% %gpufan% %gpuvolt% %gpupowertune%
sleep 300
taskkill /im cgminer.exe /f
<nul set /p =%threadconcurrency%: >> AvgHashrateTC.txt
grep -i "(avg)" %threadconcurrency%.txt | tail -1 >> AvgHashrateTC.txt
set /a threadconcurrency=threadconcurrency+64

goto :startloop

miner-tc-r9version.bat

@echo off
set threadconcurrency=%1
set gpuclock=%2
set memclock=%3
set gpufan=%4
set gpuvolt=%5
set gpupowertune=%6
cgminer --scrypt -o stratum+tcp://coinotron.com:3334 -u trogdorjw73.tester -p tester -w 256 -v 1 -I 20 -g 1 -T --gpu-engine %gpuclock% --gpu-memclock %memclock% --gpu-fan %gpufan% --gpu-vddc %gpuvolt% -- --temp-target 80 --temp-overheat 95 --temp-cutoff 99 --thread-concurrency %threadconcurrency% > %threadconcurrency%.txt
exit

The first files starts with some variables you can modify for clock speeds, starting thread concurrency, voltage, fan speed, and powertune. It the calls the second file (passing the variables along), which actually starts CGMiner running. Because we can't let CGMiner exit gracefully without a BSOD, the first file waits 300 seconds after starting the second file and then kills the CGMiner.exe process, at which point it uses the output from the mining results and grabs the last average hash rate, which ends up in a text file called AvgHashrateTC.txt.

So to use this, you first need to delete (or at least rename) your cgminer.conf file in your CGMiner folder, then extract the Zip file to the directory and just run thread-concurrency-test-r9version.bat and walk away (though you might want to tweak the clocks or other settings first). Come back in a day or so and look at your averages and you'll see something like the following:

18000: (29s):1.398M (avg):1.569Mh/s | A:640   R:0    HW:627  WU:616.8/m
18064: (29s):1.368M (avg):1.565Mh/s | A:1600  R:0    HW:710  WU:610.6/m
18128: (29s):1.264M (avg):1.585Mh/s | A:1600  R:0    HW:537  WU:608.4/m
18192: (29s):1.330M (avg):1.536Mh/s | A:1600  R:0    HW:600  WU:685.5/m
18256: (29s):1.409M (avg):1.575Mh/s | A:1920  R:320  HW:347  WU:707.8/m
18320: (29s):1.339M (avg):1.544Mh/s | A:2240  R:0    HW:467  WU:626.2/m
18384: (29s):537.3K (avg):1.357Mh/s | A:640   R:0    HW:384  WU:681.4/m
....

If all goes well, you will have a lot more lines than the above, but it's possible your system will crash during the testing. To get around that, the currently tested TC is spit out to a file which gets read when the first batch file starts. If you create a shortcut to thread-concurrency-test-r9version.bat and put that in your Startup folder, even after a crash/reboot the testing will pick up where it left off.

In the meantime, based on more experience with the GPUs, I'm recommending the Radeon R9 290 over the R9 290X for Windows users -- you can probably get closer to 1000KHash/sec on the 290X with Linux, but on Windows it can be rather difficult. Also, the default voltage used on your GPU will affect your ability to hit higher clocks and hash rates -- lower voltages being better.

Donations gladly accepted if this helps you out:
LTC: LXpEZcNJtikd263z7Ha3vrdYDcLU7hiKWv
Go win some LTC!