Thanks for the responses. I'm still confused, but I've been that way my whole life. 

I've been thinking about this, and I'm still not sure what the reason for selling ASIC miners is. It seems like an arms-race. If I increase my own H/s rate, I mine more BTC, but if I sell the ASIC-based miners I created, I increase basically everyone's H/s so difficulty increases, and we end up mining BTC at the same rate as before. We are constantly throwing more and more resources at the problem, in the form of ever-increasing H/s, but it never gets us anywhere any faster. The only way a new technology is really meaningful in BTC mining is when only a few entities have access to it. Once it is mainstream, it no longer helps increase anybody's H/s.

Now that I re-read that, it seems like an environmentalist's nightmare. We are expending more and more energy to get the same overall return and there's no need for it. If efficiency was a goal, we'd all just run Raspberry Pis. The difficulty would go down, but the BTC mining rate would stay fairly constant. We'd reduce the power consumption by 100-fold, without reducing the resources produced per time.

I think everyone should ditch their ASICs and GPUs and only mine on slow ARM chips to save the environment. We want to be "green" as a community, don't we?
 

Just a completely uneducated guess from a newbie: but could it be heat be a problem? Maybe you aren't moving enough air (or cold enough air) to keep 4 of them from getting too toasty?

Can you run 2 without issue? How about 3?

Ok, this might be a dumb question, but they always say the only dumb questions are the ones you already know the answer to.

I've been looking at the various ASIC miners that are available, and I'm not sure I understand why they are being sold at all. For example, let's look at the Butterflylabs offerings: say the 25 GH/s model. They are selling them for $1249 on their web site. If I plug 25000 MH/s into a bitcoin mining calculator it comes up with just over $1000/mo. So, ignoring electricity, the thing should potentially pay for itself in about 5 weeks. How is this possible? Even if the value of BTC falls to half of what it currently is, or the difficulty doubles, you are still looking at less than 3 months to recover the initial $1249 investment.

So, if you were Butterflylabs, why would you sell these things? It seems like the prudent thing to do would be not to sell them at all, and just run all of them yourself until you had more BTC than anybody else. I'm kind of feeling like this is a similar deal to the "I'll tell you how to make $1,000,000 in the market with a $100 investment in only 6 months. Just send me $49.95." scams. If they really can make $1,000,000 in the market with $100, why would they be selling that info for $49.95, instead of just making a killing in the market?

So, what am I missing? How is selling the ASIC mining hardware a better business model for the hardware manufacturer than just running the miners themselves?

This isn't meant to pick on Butterflylabs; it's a generic question about all ASIC miners. I just had to pick somebody as an example.

I don't have any direct experience with this, but my guess would be extremely cold. Take a look at some of the "extreme" overclocking websites where they discuss phase-change cooling. You can get down way below zero with a phase-change setup. It works like a refrigerator or air conditioner. There's a compressor and evaporator and it is filled with freon (or something like freon). The biggest worry is condensation of the humidity in the air on the cold plate attached to your GPU (and/or CPU). You need to insulate the cold parts very well to keep water out of your computer.

You can also use dry ice, liquid nitrogen, or liquid helium to cool your CPU/GPU to extremely cold temps. This is what the world-champion overclockers do. Unfortunately, you can't run 24/7 on any of those technologies; the dry ice (or LN2 or LHe4) evaporates and must be constantly replenished.

If you really can force -20C air into your case, you should be fine. Since you will be blowing air through the case, you shouldn't have a condensation problem like you would with phase-change cooling. You probably can't hurt the GPU itself with cold. Heat is a killer, but cold won't do any long-term damage.

Sorry this is in the newbies section, but I registered to this forum specifically to post this, and I'm not yet allowed to post on the cudaminer thread. Maybe an admin can move this post to the proper place if it is deemed worthy.

I just managed to get cudaminer to build on Linux, and figured I should document what I had to change to make things work because the Linux instructions in the cudaminer thread don't work for me. This worked for cudaminer-2013-07-13.zip. You will (obviously) need the NVidia CUDA SDK installed and "nvcc" in your path.

First, after unzipping the archive and un7zing the src archive. I had to remove all of the ^Ms from the line endings or autotools gets confused and generates a configure that doesn't work:

dos2unix *

Then the main file is called "cpu-miner.c" but autotools seems to be set up for a file called "cuda-miner.c" We'll just copy it over to make autotools happy:

cp cpu-miner.c cuda-miner.c

Now you should be able to generate the configure script using autogen.sh:

chmod 755 ./autogen.sh
./autogen.sh

The configure script picks the wrong C compiler by default. It tries to use gcc, but we really need g++ for this because there are a couple of C++-isms in the source that gcc doesn't like. I also had a problem where it couldn't find the CUDA libraries, but that might just be my cuda-sdk install or something wonky with my distro, but it can't hurt to specify. So, we'll set CC and LDFLAGS to compensate when we run ./configure

CC=g++ LDFLAGS=/opt/cuda/lib64 ./configure

Hopefully, things will go well and you will have a Makefile.

Now, there are still a couple of things that I needed to tweak in the code. First off, I was continually getting "'sleep' was not declared in this scope" errors, and similar errors for other functions in unistd.h. I still have no idea why. The #include <unistd.h> should have worked, but I had to specify the full path to make it work for some reason. Only do this if you are getting the sleep errors. It might just be something wrong with my environment, but oddly it only affected unistd.h. Anyway, in the cuda-miner.c file, I changed:

#include <unistd.h>

to

#include "/usr/include/unistd.h"

Then, there's a call to _strdup() on line 1251 in that same file. I don't really know why there's an underscore there, but I don't have a library with a function by that name and the non-underscore version seems to work. So change:

device_config[cnt++] = _strdup(pch);

to

device_config[cnt++] = strdup(pch);

We should be done with cuda-miner.c now.

The last probelm I had was a call to alloca() in util.c that doesn't cast the void* to a char* to match the type of the pointer. We just need to add a cast to make the compiler happy, so on line 84 in util.c change:

buf = alloca(len);

to

buf = (char *) alloca(len);

And everything should be good to go. Type "make" and if you are very lucky (and I didn't change anything else I've forgotten about) it should compile for a while then you should have an executable file called "cudaminer" in the current directory. I've been running it from there, and did not run a "make install." It's probably not needed.

I've been running it for a bit, and it seems to be working. At least the mining pool I use has been accepting the work; that's as far as I know how to test it. It's probably a 2x speed improvement over cgminer on my GTX 670, which is awesome!

Oh, and thanks for your work on this cbuchner1. I will probably donate some LTC to you, once I've mined enough to cash out some LTCs of my own.