I had the same thing happen to my cube, was working fine, came back a couple of hours later and the fuse was smoked, cooked the main board pads. I had to solder an external wired fuse holder in to get it working (it actually cooked holes through the fiberglass main board).
I doubt it is caused by an over supply, that should just blow the fuse. In my case I suspect a faulty connection that caused the fuse holder to over heat.

Yes, I'm lucky, I have free power, I "could" run as many cubes as the house circuits could handle (240v ac)
Been wondering if I could run an Antminer and a cube on a corsair GS 800 psu.

Now for some depressing reading.

Jan 5 -Jan 12 0.1 bt
Jan 12 - Jan 22 0.1 bt
Jan 22 - 3 Feb 0.1 bt
Feb 3 - Feb 18 0.1 bt
Feb 18 - 9 Mar 0.1 bt
Mar 9 - 4 Apr 0.1 bt
Apr 4 - May 11 0.1 bt

Single cube over clocked, running 24/7 at 38793 GHs.

So, will it ever generate 2 whole bitcoins?

Gateway is set to 0,0,0,0  Set it to the IP of the router

Statistically, you could find a block in the first 30 seconds, then again it might not happen till after the end of the universe. And it will get to the point where a single cube is not capable of generating enough in a pool to pay for the power used to run it. Doubling down doubles the return for double the cost. So, there is a perverse logic in going for broke.

So, question, how long will it take a single cube to generate 25 bitcoins? (the only valid answer is twice as long as half of it)

I would try adding a pair of large caps (10,000 uf) to the PCIe connectors as per the earlier parts of this thread,if it is voltage drop condition and it is only while the cube is starting then that may fix the problem, if, however the PSU cannot supply the continuous voltage necessary then that will make no difference.

It's a bit of potluck with the exact speed you get on HI. All you can do is switch to Hi and make sure there are no bottlenecks in the system.

My cube runs consistently at 38,7xx with slushs proxy running on a raspberry PI

This company? appears to be a scam


http://www.xtrememiners.net/

Based in Germany. It is, apparently, a legal requirement in Germany to have a contact phone number and a tax file on business web sites.
Company address is bogus.
Phone conversations are apparently being done through VOIP and are routed from Hong Kong / China via the USA.
Email responses are 6 to 8 hours out of sync with Euro times.

You need to provide more information.

Whats the cube setup, what config options are used on the proxy

What else is on the network etc

You should have 2 green power LED's I presume the it s one for each PCIE plug. I am not sure if the green LEDS are pre fuse or post.

If the LEDs are powered post fuse then it may be the fuse that is the problem. In my cube the fuse holder or the soldering to the MB was faulty, the fuse over heated and destroyed itself, the fuse holder and burned a hole in the MB. I had to solder in an external fuse holder to resurrect the unit.

And you pretty much HAVE to strip the cubes BEFORE powering up to ensure that the blades have not become dislodged in transit and that the heatsinks are secured properly. The latter problem will cause overheating and the former could smoke the whole unit

The real problem is this

IamCANADIAN 

My immediate take on this is it's a power problem but not necessarily the power supplies. Are the PSU's all plugged into the same circuit (they may be on different plugs which are on the same wiring circuit). Thats a lot of amps to drag off one circuit especially if you are 110 volts (rule of thumb is, if you double the voltage you halve the amperage needed to do the same amount of work)

your path\mining_proxy.exe -q -rt

That will, by default connect to slush's pool. The -q switch reduces (not stops) the amount of crud sent to the monitor and the -rt switch allows for variable difficulty which reduces the network traffic and the load on the server.

you can run the stratum proxy with the following command line

"mining_proxy"   it defaults to slush's pool so you only "NEED" the port settings for other pools.

You can also add the -q switch, reduces the amount of crud it prints to the screen
and the -rt switch, allows the difficulty to vary according to the  power of your cube.

Have you got the Python runtime installed?

Try setting your default gateway to 192.168.1.1

I would strip both cubes, label one MB "A" the other "B" and the blades "A1,A2 .....B1, B2" etc
then move all A's blades to B and B's to A, try that if the fault moves to the other MB you have a faulty blade, if it not you have a faulty MB.
If it is a blade that is faulty, plug each blade in and test till you identify the faulty one. Then hit up your supplier.

You could always try and replace the scorched cap and see if the blade runs, I would wait and see if they will replace it, if not try and repair it, you have nothing to lose.



In the pool address's you will have 2 IP address's separated with a comma. If you are only using 1 pool you would have that pool's IP address entered twice separated with a comma. If you want to use a different fall back pool just change one of these IP address's to point to the second pool. The pools button on the interface allows you to cycle through the pools. You may be able to put in more than 2 address's, haven't tried it tho

My take on that is that it is starving for work, try pointing that one cube to a stratum proxy of it's own

That is just verbage.

Check the status page for your cube.

For low clock you want no X's and a hash rate of around 32
For Hi clock, again, no X's and a hash rate of around 38.

The hash rate will build slowly but should settle in under 10 minutes

Direct connect the cube to the Computer. Change the IP address to whatever format you have decided on then reconnect thru the router