These guys have a two-state internal regulator, so when you switch to High Clock it adjusts the voltage output automatically to work with the higher clock. Shouldn't need manual adjustments - which is good because the parts for manual adjustment don't exist. It's built to work high/low without messing with the innards.

If I can get a simple solution figured out for improved cooling, it might be possible to run faster than the standard High Clock. I've got a test rig that's peaked out at 39.8GH, cooling is keeping it from going faster until I get some more parts in. Should run about 43GH.

Also, Cubes make excellent space heaters. Relatively quiet and fairly power-dense. Probably gonna fetch more and just leave them in various rooms around the house.

You might consider seeking a warranty replacement from where you bought it from, or talk to FriedCat. Not sure what their policy is on hardware issues, but I think shipping with an entire bank of chips down is grounds for a replacement already.

If you temporarily change a machine's IP to the 192.168.1.x subnet and access the Cube's config page, you can change its IP over to 192.168.2.x subnet and update the settings, it should work without needing a change to your network.

Okay, that is strange. Reckon it's a credentials issue or something with the pool?

PM sent.

What did you type in the command line when you ran the proxy? Did you specify a pool? You're gonna want something like

mining_proxy.exe -o mint.bitminter.com -p 3333 -gp 8332


If you don't specify a pool in the command line, it defaults to slush.


What hashrate, shares per minute, and efficiency are reported on the blade config?

What I've done is get the 8x8x30 heatsinks, cut 4 in half and leave 8 whole. 1.5 heatsinks will span 4 chips on the blade.

On the subject of power supplies - I'm working up some 750W supplies rebuilt to run two Cubes natively; had one running two at full overclock for a few days with no issues. Basically modified server supplies, so high reliability and about 90% efficiency. Won't require a paperclip, and can actualy be turned on with a switch or from any external voltage (molex connector). Should have word in a few days about selling.

Also testing additional-overclock feasibility, but so far heat is a limiting factor. Best speeds I've gotten are around 39.6GH.

Just throwing that out there.

These guys on eBay have a decent selection of chip-sized heatsinks and ship from the US.

http://www.ebay.com/usr/diyfancylights

That I'm not sure on. I don't see any failover or backup references in the help (mining_proxy.exe -h). With blades specifically though, they require two servers to be configured so if you set failover there, if the mining proxy can't connect to stratum the blade should switch to its backup server after around two minutes. You can configure a backup proxy, or point straight to a pool's getwork server.

Not sure what conflicts would arise from running two instances of stratum proxy. If you use the -gp option, you can specify a different port for the proxy to listen on; it may be possible to run two concurrent proxies aimed at different pools, listening on different ports, so when the one fails, the blade will automatically connect to the second when it times out.

Try this:

Stratum proxy on desktop
Desktop plugged into LAN port on router
Blades plugged into LAN port on router
Blade's IP changed to 10.42.0.x range, 10.42.0.1 gateway, 10.42.0.1 server


Most of what a router does through the WAN port, your desktop is already doing. You should be able to use it as a switch with wireless. If you have more blades, it should work to plug them into the hub and then plug *that* into a LAN port on the router.

It looks to be that BFG's stratum proxy is not implemented for Win64

Also, Slush's mining proxy can be used for other pools:
mining_proxy.exe -o pooserver -p stratumport

If you have a separate switch, you could put that between the desktop and the router and tie your blades into it, then run the stratum proxy on the desktop. Since they're only looking on local network and have fixed IP, they won't really need the router at all.

The only other thing I can think of is to run some ICS/DHCP on the desktop and use it to route packets, then plug the desktop into LAN ports on the router which would be used as a switch. Depending on what you have running on the desktop to send internets to the router, you may not need the router's actual routing funtions at all - it may only really be doing DHCP IP address assignment for your laptop, which you wouldn't need if you manually assigned an IP. DHCP might still be available even if you only use the router as a switch with wireless (ie plug into the LAN port instead).

Ah, I didn't even realize that was you, didn't check username when reading. Good to see you got the one working well.

A few.

Total MHS:   14917
Received:   0000641329
Accepted:   0000635947
Per Minute:   203.83
Efficiency:   099.16%
Up Time:   2d,03h,59m,51s

Current Server: 192.168.2.239:8332
Chip: OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO

No, that's a good thing. It'll probably converge after a while, to around 97-99 percent depending on power quality and cooling.

Good to see you got it working. Connected with slush's proxy?

Very true. All the blade heatsinks I've seen had very rough surfaces, lots of extrusion grooves. Oftentimes the boards were raised slightly above the surface too, which hurts thermal conduction even more.

There's only two ways to run a blade. Point the blade at your pool's Getwork, or point the blade at a proxy and point the proxy at your pool's stratum.

Also the pool might take up to ten minutes to report the additional hashrate. Make sure the blade's user credentials are correct for your pool account.