[Guide] Dogie's Comprehensive ASICMiner Cube Setup [HD]

[Damnsammit]

I've had luck with running two cubes on one Corsair TX850 and three Cubes on two CX750's.  Of course a single Cube will run on either of these PSUs.

This should be more than enough to run one, yes?  Just trying to make sure I have everything ready to go so I can start mining as soon as the Cube arrives...

http://www.newegg.com/Product/Product.aspx?Item=N82E16817152026

On paper yes, but in reality it probably won't last long. Cheap branded PSUs are just that unfortunately, cheap and ready to break. They have to save money building them somehow, right?

Well if it decides to crap out then I will pull the 850W Antec from my mining rig and then go get a new one for it

[1714497961]

1714497961

[1714497961]

1714497961

[1714497961]

1714497961

[dbell]

Have two cubes up and running but Hash rate varies all over them map and dies down to zero often.

I am using the statum proxy server approach.   I did not have a free local machine to set up the proxy server on so we quickly set one up on an Amazon cloud machine.   I have never seen either cube get higher than 22 GH and now they are mostly spending time down near zero.

I an thinking that it may be some proxy issue or tuning that I don't understand.  Maybe I need to run a localized server to make this work and I should just pick up a Rasberry Pi and set up one?

I know he cubes can work, it is just seems to be some network or server issue.  I am leaning to the server side but I don't have enough experience.

Thoughts or insight?

- - - - - -

I also tried to connect to some of the pools directly using the Getwork pool address but get no action.  Is that worth more investigation or stick with the stratum server?


On Getwork:
Doesn't seem to connect to Eligius getwork pool directly.

Pool ports set to: 8337,8337
Pool address: getwork.mining.eligius.st,getwork.mining.eligius.st
Miners users/pass: addresss:pass,address:pass

It looks like no jobs are being received from eligius.

Am I doing something wrong?

You need a local machine. Any sort of delay on those packets will make them useless and discarded as either stales or add in idle times. You must must must must must set up a local machine, or run getwork. Isn't eligius's server at mining.eligius.st?

Thanks dogie!   Eligius may not be supporting getwork anymore.  I should have seen that the Eligius note page http://eligius.st/~gateway/news/important-upcoming-changes-mining-hostnames I got the get address from was from back in May 2013 and the main page on Eligius no longer shows getwork host name or address. 

Looking at Eligius stats for the two machines,  in the early morning hours packet traffic got light enough to allow both cubes to average 30 GH for 10 or 15 minutes even with our remote stratum sever on the cloud.... then crashing back done later in the morning.

Time for a local stratum server.... much thanks again

[dogie]

Thanks dogie!   Eligius may not be supporting getwork anymore.  I should have seen that the Eligius note page http://eligius.st/~gateway/news/important-upcoming-changes-mining-hostnames I got the get address from was from back in May 2013 and the main page on Eligius no longer shows getwork host name or address. 

Looking at Eligius stats for the two machines,  in the early morning hours packet traffic got light enough to allow both cubes to average 30 GH for 10 or 15 minutes even with our remote stratum sever on the cloud.... then crashing back done later in the morning.

Time for a local stratum server.... much thanks again

No problem. Your mining revenue should easily pay for a $300 laptop within a few days - especially considering your $300 is still worth $250 in a few months.

[dbell]

In the mean time I found the Ozcoin  http://ozco.in/  still supports getwork.  I setup an account, pointed both cubes to their getwork host and port and the cubess are both hashing at 27GH now.  I will still set up the local stratum server to try to get the reported 38GH out of each cube but this interim approach at least gets me hashing consistently at reasonable rates.

Ozcoin has US local IP address for the getwork protocol and a two different access ports.

May help someone get started quickly if they don't immediately have a stratum server.

[Thyatis]

Good price on the corsair HX modular 850 powersupply $149 at amazon.com

http://amzn.to/1bNDbaV

[lajz99]

For the past few days I've been using bfgminer as a proxy connecting to ghash.io and I've only been getting 32-33gh/s on high.  Today I switched over to slush's pool using his proxy and I'm getting 37gh/s+ no problem.  (speeds are based on miner not pool)

Why is this?

[edgie13]

First off, thanks to everyone for their suggestions and to Dogie for this great guide!

I decided to take my cube and psu to a different friend's house.  It works perfectly there!  It is like Dogie said,  "mysterious network topology" was my issue.  My friend is going to host my cube until I figure this out.  Thanks again.

[dogie]

For the past few days I've been using bfgminer as a proxy connecting to ghash.io and I've only been getting 32-33gh/s on high.  Today I switched over to slush's pool using his proxy and I'm getting 37gh/s+ no problem.  (speeds are based on miner not pool)

Why is this?

While I've not used BFG extensively, I do think the barebones proxy is simply more efficient.

First off, thanks to everyone for their suggestions and to Dogie for this great guide!

I decided to take my cube and psu to a different friend's house.  It works perfectly there!  It is like Dogie said,  "mysterious network topology" was my issue.  My friend is going to host my cube until I figure this out.  Thanks again.

One thing you can check is any phones connected to your wifi. Not sure how they interfere, but a few users of V1 blades found phones [android?] were preventing it working correctly.

[Damnsammit]

One thing you can check is any phones connected to your wifi. Not sure how they interfere, but a few users of V1 blades found phones [android?] were preventing it working correctly.

That is good to know! I got two phones and a iPad on my wifi

[Chris_Sabian]

When I try to connect to the Guild with the stratum proxy, sometimes I get this error:



The proxy works fine with Slush.

My bat file:
cd C:\Mining
mining_proxy.exe -o stratum.btcguild.com -p 3333

Problem with the server?

I have several cubes each with its own worker ID.

**EDIT**

I changed the worker ID on the cubes to only 2 different worker names and it appears that I no longer receive the error.  However, 2 of the cubes are maxing out at ~25 Gh/s and the others are at ~35 Gh/s

[babaji.ca]

Hi Guys,

Nice thread Dogie, great reading!

I am wondering if you think Will this PSU handle 3 cubes?

http://www.amazon.com/Seasonic-SS-1050XM-1050-Power-Supply/dp/B00607JL5C/ref=sr_1_1?ie=UTF8&qid=1386381067&sr=8-1&keywords=SeaSonic+X-SERIES+X-1050

Also wondering if running a stratum proxy requires a lot of resources? Just wondering if my Raspberry PI will be able to handle it all the while running a few other instances of Cgminer and or BFGminer for my collection of other devices and pools.

[Chris_Sabian]

When I try to connect to the Guild with the stratum proxy, sometimes I get this error:

**Update**

When several of the cubes turned on, the jumped to hashing at ~25 Gh/s almost immediately.  Over the next 1 - 1/2 hr they slowly climbed to 36-38 Gh/s.  They seem to be rather temperamental at times.

[dbell]

Have two cubes up and running but Hash rate varies all over them map and dies down to zero often.

I am using the statum proxy server approach.   I did not have a free local machine to set up the proxy server on so we quickly set one up on an Amazon cloud machine.   I have never seen either cube get higher than 22 GH and now they are mostly spending time down near zero.

I an thinking that it may be some proxy issue or tuning that I don't understand.  Maybe I need to run a localized server to make this work and I should just pick up a Rasberry Pi and set up one?

I know he cubes can work, it is just seems to be some network or server issue.  I am leaning to the server side but I don't have enough experience.

Thoughts or insight?

- - - - - -

I also tried to connect to some of the pools directly using the Getwork pool address but get no action.  Is that worth more investigation or stick with the stratum server?


On Getwork:
Doesn't seem to connect to Eligius getwork pool directly.

Pool ports set to: 8337,8337
Pool address: getwork.mining.eligius.st,getwork.mining.eligius.st
Miners users/pass: addresss:pass,address:pass

It looks like no jobs are being received from eligius.

Am I doing something wrong?

You need a local machine. Any sort of delay on those packets will make them useless and discarded as either stales or add in idle times. You must must must must must set up a local machine, or run getwork. Isn't eligius's server at mining.eligius.st?

Thanks dogie!   Eligius may not be supporting getwork anymore.  I should have seen that the Eligius note page http://eligius.st/~gateway/news/important-upcoming-changes-mining-hostnames I got the get address from was from back in May 2013 and the main page on Eligius no longer shows getwork host name or address. 

Looking at Eligius stats for the two machines,  in the early morning hours packet traffic got light enough to allow both cubes to average 30 GH for 10 or 15 minutes even with our remote stratum sever on the cloud.... then crashing back done later in the morning.

Time for a local stratum server.... much thanks again

Got the local stratum server up and running on a Raspberry Pi, under Debian Linux.  The local server is pointed at Eligius.  Both the cubes and the Raspberry Pi server are all hardline connected to a switch which is hardline connected to the incoming AT&T router.  The Hashing performance is now very very stable but only running 23 GH on each cube with almost identical performance and ASIC chip loading profile on both cubes. 

Clock rate makes no difference.   

Example Local Single Cube performance reports as:
M_01-16: 308 313 395 329 362 294 307 318 316 354 351 334 315 318 335 316
M_17-32: 343 322 338 294 312 295 328 321 304 267 323 281 311 330 277 318
M_33-48: 313 331 301 304 312 322 306 294 332 358 275 325 309 279 337 267
M_49-64: 229 320 299 341 273 306 275 270 312 250 215 296 280 264 257 200
M_65-80: 256 227 151 207 193 195 164 136 136 164 124 082 093 062 072 068
M_81-96: 048 030 022 031 016 016 017 013 020 013 011 019 011 012 008 011
Jobs:0000025554 Accepted:0000022770 Rejected:0000000147 (0:2) F1 F2 F3
MHS:22262 Utility:304 Efficieny:089.10%

Is is normal for the utility of the higher number ASIC chips to taper off toward zero if the protocol can't keep up with providing work to the cube?  I am leaning to this conclusion since both cubes show similar ASIC chip loading pattern shown above with one to one and half of a board/bank not showing full Utility

If I take one cube off-line, the remaining cube still sits at 23 GH, no hashing improvement.  Bringing the second cube back on-line again, it quickly builds up to 17 GH and then slowly climbs back to 23 GH over the next few minutes.

Eligius reporting of hash rates for each cube matches the locally reported hash rate, as expected.

Where is my performance bottleneck coming from?

I am taking opinions and ideas.

Thanks

[dbell]

Have two cubes up and running but Hash rate varies all over them map and dies down to zero often.

I am using the statum proxy server approach.   I did not have a free local machine to set up the proxy server on so we quickly set one up on an Amazon cloud machine.   I have never seen either cube get higher than 22 GH and now they are mostly spending time down near zero.

I an thinking that it may be some proxy issue or tuning that I don't understand.  Maybe I need to run a localized server to make this work and I should just pick up a Rasberry Pi and set up one?

I know he cubes can work, it is just seems to be some network or server issue.  I am leaning to the server side but I don't have enough experience.

Thoughts or insight?

- - - - - -

I also tried to connect to some of the pools directly using the Getwork pool address but get no action.  Is that worth more investigation or stick with the stratum server?


On Getwork:
Doesn't seem to connect to Eligius getwork pool directly.

Pool ports set to: 8337,8337
Pool address: getwork.mining.eligius.st,getwork.mining.eligius.st
Miners users/pass: addresss:pass,address:pass

It looks like no jobs are being received from eligius.

Am I doing something wrong?

You need a local machine. Any sort of delay on those packets will make them useless and discarded as either stales or add in idle times. You must must must must must set up a local machine, or run getwork. Isn't eligius's server at mining.eligius.st?

Thanks dogie!   Eligius may not be supporting getwork anymore.  I should have seen that the Eligius note page http://eligius.st/~gateway/news/important-upcoming-changes-mining-hostnames I got the get address from was from back in May 2013 and the main page on Eligius no longer shows getwork host name or address. 

Looking at Eligius stats for the two machines,  in the early morning hours packet traffic got light enough to allow both cubes to average 30 GH for 10 or 15 minutes even with our remote stratum sever on the cloud.... then crashing back done later in the morning.

Time for a local stratum server.... much thanks again

Got the local stratum server up and running on a Raspberry Pi, under Debian Linux.  The local server is pointed at Eligius.  Both the cubes and the Raspberry Pi server are all hardline connected to a switch which is hardline connected to the incoming AT&T router.  The Hashing performance is now very very stable but only running 23 GH on each cube with almost identical performance and ASIC chip loading profile on both cubes. 

Clock rate makes no difference.   

Example Local Single Cube performance reports as:
M_01-16: 308 313 395 329 362 294 307 318 316 354 351 334 315 318 335 316
M_17-32: 343 322 338 294 312 295 328 321 304 267 323 281 311 330 277 318
M_33-48: 313 331 301 304 312 322 306 294 332 358 275 325 309 279 337 267
M_49-64: 229 320 299 341 273 306 275 270 312 250 215 296 280 264 257 200
M_65-80: 256 227 151 207 193 195 164 136 136 164 124 082 093 062 072 068
M_81-96: 048 030 022 031 016 016 017 013 020 013 011 019 011 012 008 011
Jobs:0000025554 Accepted:0000022770 Rejected:0000000147 (0:2) F1 F2 F3
MHS:22262 Utility:304 Efficieny:089.10%

Is is normal for the utility of the higher number ASIC chips to taper off toward zero if the protocol can't keep up with providing work to the cube?  I am leaning to this conclusion since both cubes show similar ASIC chip loading pattern shown above with one to one and half of a board/bank not showing full Utility

If I take one cube off-line, the remaining cube still sits at 23 GH, no hashing improvement.  Bringing the second cube back on-line again, it quickly builds up to 17 GH and then slowly climbs back to 23 GH over the next few minutes.

Eligius reporting of hash rates for each cube matches the locally reported hash rate, as expected.

Where is my performance bottleneck coming from?

I am taking opinions and ideas.

Thanks

Well I am talking to myself here on-line but it will be perhaps useful for someone.    I have to eat my words from the previous post.  I took one of the two cubes off-line again and waited longer.  This time the one remaining cube indicated a very slow rise in local hashing rate.

On the other hand, the Eligius site showed a much more rapid rise in Hash Rate for this one cube, in fact showing it going up to the full over clocked rate of 37 to 40 GH.  Not sure why the locally reported hash rate climbs so slowly but both the slow rise in local has rate and the indications on Eligius show these cubes are fully capable and I am dealing with some sort of protocol bottleneck on my end.  Maybe two instances of the Stratum proxy server might help.  If not I will try moving around some network elements.  If all of that fails, move one cube to a much different network location and give it its own Raspberry Pi.  All very interesting.

[Coinmart]

Can anyone see my issue of why I can't get running? Any help appreciated.

http://imagizer.imageshack.us/v2/xq90/89/0lln.jpg

[sidehack]

On the other hand, the Eligius site showed a much more rapid rise in Hash Rate for this one cube, in fact showing it going up to the full over clocked rate of 37 to 40 GH.  Not sure why the locally reported hash rate climbs so slowly but both the slow rise in local has rate and the indications on Eligius show these cubes are fully capable and I am dealing with some sort of protocol bottleneck on my end.  Maybe two instances of the Stratum proxy server might help.  If not I will try moving around some network elements.  If all of that fails, move one cube to a much different network location and give it its own Raspberry Pi.  All very interesting.

Part of the reason the local hashrate climbs slowly is, if I'm thinking right, the local is a time integral average. If it ran at 25 for three hours, then ran at 35 for three hours, after six hours your local would still only report 30. The pool's displayed rate is probably resampled every few minutes, so it would more likely display the current output accurately.

Also, not sure if it's a getwork limitation or not, but the bottom row of chips is the leftmost card (looking from the fan side), which has the worst cooling ability of any of them - its heatsink is up against the edge of the housing, with basically no fan coverage - so it's going to be the lowest performer no matter what you do.

[Chris_Sabian]

When I try to connect to the Guild with the stratum proxy, sometimes I get this error:

**Update**

When several of the cubes turned on, the jumped to hashing at ~25 Gh/s almost immediately.  Over the next 1 - 1/2 hr they slowly climbed to 36-38 Gh/s.  They seem to be rather temperamental at times.

Guess I posted too quickly, the proxy gave the same error for most of the night.  I had ~1,000 shares accepted after 8 hrs.  The proxy gives the same error on 2 different computers with BTCGuild.  The proxy also is horribly slow with Slush.  Anyone have luck with BFGminer instead?

[Chris_Sabian]

Can anyone see my issue of why I can't get running? Any help appreciated.

I have the same / similar issue

[Coinmart]

I have the same / similar issue

Looks like we have similar config going through guild.

[dogie]

On the other hand, the Eligius site showed a much more rapid rise in Hash Rate for this one cube, in fact showing it going up to the full over clocked rate of 37 to 40 GH.  Not sure why the locally reported hash rate climbs so slowly but both the slow rise in local has rate and the indications on Eligius show these cubes are fully capable and I am dealing with some sort of protocol bottleneck on my end.  Maybe two instances of the Stratum proxy server might help.  If not I will try moving around some network elements.  If all of that fails, move one cube to a much different network location and give it its own Raspberry Pi.  All very interesting.

Part of the reason the local hashrate climbs slowly is, if I'm thinking right, the local is a time integral average. If it ran at 25 for three hours, then ran at 35 for three hours, after six hours your local would still only report 30. The pool's displayed rate is probably resampled every few minutes, so it would more likely display the current output accurately.

Also, not sure if it's a getwork limitation or not, but the bottom row of chips is the leftmost card (looking from the fan side), which has the worst cooling ability of any of them - its heatsink is up against the edge of the housing, with basically no fan coverage - so it's going to be the lowest performer no matter what you do.

Blade interface MH is done over a 5 minute period. Your last card isn't mining right, all its MH values are essentially zero. Are you sure you're power supply is up to powering 3?