I was GPU-mining BTC in 2011 and shut down my operation after a few months having earned 154 BTC because I was "only" making 5 BTC per week. At the time, I was only breaking even with my electricity costs, so I figured, "Why bother?" and quit. Sold all 154 coins a while later for $10/each.

Ugh.

I've found that data returned by Kraken's OHLC API function is highly inconsistent. It is clear that the data returned by the API for "committed" (historical data) frames changes over time. Often by very large amounts!

To demonstrate this, I ran two identical API calls (simply using my web browser) approximately one minute apart. See the screenshots below. I would have expected committed/historical OHLC frames to remain static over time, but this is not the case. Am I doing something wrong or misunderstanding how this is supposed to work?

http://i.imgur.com/tNPP0Rq.png

http://i.imgur.com/p2xtIzk.png

Historically, difficulty and exchange rate have shown correlation. However, correlation != causation.

One could argue that increase in difficulty helps drive increase in value, but difficulty is only one of the many factors that must be considered.

For the past, present and near future, the most important factor, besides difficulty, that affects BTC exchange rate is speculation of its future value. These two factors, are the major drivers of exchange rate. Alas, while difficulty is a concrete measurement, speculation of future value is not so easily measured.

I suggest that you change the header to be static instead of floating. Having a floating header permanently reduces the viewable area of each page by 30% on my laptop. Also, it makes the site utterly unreadable on mobile devices such as tablets and phones, because the header is incorrectly positioned and appears right in the middle of the screen.

Imagine reading a book where every page had the title of the book on the top... Doesn't make much sense.

+1

I wish you and yours the best...

I had a thought that it might be nice to automate backups of the wallet file.
Certainly this is not beyond the realm of moderately advanced users already, through scheduled system tasks/cron/whatnot, but those are not the ones who are likely to find themselves with a corrupted or deleted wallet, or a too-old wallet backup. I've found that even moderately technical people still fail to understand that wallet backups decay over time.

How would the community feel about the addition of an automated wallet backup option - through the standard backup interface, give the option to automatically take a new backup whenever new private keys are added to the wallet. Bonus points if the backup screen can detect the presence of cloud storage folders (eg. dropbox) to suggest these locations. Perhaps it would be prudent in such scenarios to require the wallet be encrypted in order to enroll in automated backup.

+1

These are the two that seem to stand the best chance of surviving for at least a moderate amount of time... just my .02

That much memory is definitely overkill unless you want to do something else with that computer like run a database... Going beyond what is functionally the minimum required to run the OS + mining operation is not going to add any benefit to your operation.

580kh/s sounds about right for a 7970 at I13, though.

You will get HW errors when using cgminer intensity over 13 on the 79xx unless you set the thread-concurrency high enough to prevent worker threads from overwriting each other's memory space when operating at higher intensities. This might not improve your kh/s at all, but you can try setting your thread concurrency for the 7970 to 20480. If you get a cgminer error when starting it with that setting, it means you need to set the GPU_MAX_ALLOC_PERCENT environment variable to 100. You can do that by executing this command (only one time is necessary - don't add to batch file that starts miner)

setx GPU_MAX_ALLOC_PERCENT 100

(case-sensitive, so make sure it's all caps)

You're welcome, and in fact you don't need to do that command each time as part of your batch file. Just once is enough - it is saved as an Environment Variable after the first time you run it and it is remembered, even through system reboots and such.

I had the same problem.

Assuming you are using Windows, press and hold the Windows Key, then press R. to get the Run dialog to show.
In the run dialog, enter this and press OK:

setx GPU_MAX_ALLOC_PERCENT 100

Note that it must be entered exactly as shown. IT IS CASE SENSITIVE.

You should then be able to increase thread-concurrency, and also your intensity, without getting HW errors.

in a really great position for the long term*

They are in a really great in the long term IMO. If I had the money I would buy all your shares.

Regarding the MAX_ALLOC_PERCENT environment variable:

This setting is CASE SENSITIVE! I got stuck on this for a while. Go to your Environment Variables Settings panel:
Click the Start Button
In the search box type "var" without quotes.
Choose the "Edit the system environmental variables" option.
Click on [Environment Variables...]


Verify that MAX_ALLOC_PERCENT is present in ALL CAPS with a value of 100.

This will allow you to increase the thread-concurrency.

+1

Related video -- weather.com summer temperature forecast (for USA only):

http://www.weather.com/video/the-summer-forecast-is-in-36320

No idea beyond speculation at this point.


Sure! Here it is:
http://www.wired.com/wiredenterprise/2013/04/bitcoin-mining-rigs/

imagine it like a printing press. it takes hundreds of thousands of dollars and lots of time to build and lay out the press, but the pages it prints - the chips - are cheap and quickly produced from the expensive machine. what happened was they spent the huge amount of investment money that it takes to begin fabricating chips only to discover after receiving the first batch that they run too hot. so hot, in fact, that they basically melt the surrounding materials on the board.

i'm not making this up. there was a wired article posted with an interview of josh from bfl.

Hi there. I'm running a Windows 7 x64 machine and dual 6990's. I just switched to cgminer after having used poclbm directly launched from the command line for about 3 months without issues. Since switching, I have three problems:

1) Without fail, every time I [Q]uit the miner, it causes a BSOD. The driver reporting a failure is atikmdag.sys. I was trying Catalyst 11.5 when it started happening. Updated to Catalyst 11.9 and the behavior is the same. The only way for me to safely exit the program is to KILL the process, and then I use another program to bring the fan speeds down to normal, or reboot.

2) Attempting to set the memory clock speed to anything below 950Mhz causes instability. Anything below 900Mhz and the system locks up instantly. I've found the best course of action is to leave it at the default setting.

3) Fan speed. NO MATTER WHAT I DO, one of the fans eventually reaches 100%. Ambient temperature in the room is 68º. I never had this problem using poclbm directly. Here are my settings:
--auto-fan --auto-gpu --gpu-engine 800-900 --gpu-fan 60-75 --temp-target 85 --temp-overheat 90

I believe what is happening with the fan speed problem is that cgminer is attributing each fan to the wrong GPUs. Invariably, GPU 0 and GPU 2 are cool, at around 75º, while GPU1 and GPU3 are hot at around 89-91º. My guess is that 0+2 is one card, and 1+3 is the second card, but cgminer is thinks that the cards are 0+1 and 2+3 respectively. Therefore, it is not associating the GPU temperatures with the correct GPU fan speed settings. In fact, 0+2 used to run hotter than 1+3, because the card is physically on top of the other card in the machine. It is only so cool now because the fan is blowing so hard.

Maybe one of the 6990's is bad. Did you try the other card (alone)? Is the OC switch off (position 2)? Are both PCI-e power cables connected to the card? Try running one card alone in a different PCI-e slot.

What is the brand and model of your motherboard?
What is the brand and model of your PSU?