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

[babaji.ca]

Have you tried running it using BFGminer as a proxy. You have to have all the right dependencies when you build it. Namely libevent and libhttpd. luke jr's big long readme page about building a version of bfgminer.  https://github.com/luke-jr/bfgminer  (my ubuntu did not have the required versions of certain packages that were new enough to build it proxu support, but my rasberry pi's rasbian distro did) i find it to work better than slush' proxy,

You can also try connecting directly to eligius' pool, using gbt connection it may be better than nothing for the time being. I was able to run about 2.3 GH/s connected directly there without a proxy. maybe set it up as your 'b' address so you can toggle back and forth between it and your local proxy until you get things worked out locally. It may also tell you something about your cube or network (if things dont improve.) 

address gbt.mining.eligius.st
port 9337

(took me a bunch of tries to get it working just now, and actually its only minning at about 2300 MH/s) I got a bunch of zeros instead of mining numbers it leads me to believe you have network issues) can you try different cables, switches etc)

[Apteryx]

Have just finished setting up the stratum proxy on a raspberry pi. interestingly enough the hash rate went up from 27 and change using the stratum proxy on windows to 38 and change on the raspberry.

All in all, this has got to be about as easy as it gets, I had no problems getting the cube up and running on windows and no issues getting it running on the raspberry.

Things I did do while waiting for the power supply to turn up

Tightened all heat sink screws and made sure all blades were correctly seated.
Got a good quality PS (Corsair GS800)

Read through and then re read through this guide.

So, to all those who contributed problems and solutions, I thank you.

[Apteryx]

I too, have to wonder if these cubes are screwed... I've been struggling to get mine over 300Mhps.

I've used this thread as my guide for installation and troubleshooting.  Now I've exhausted what I think should be looked at... I'd like to get someones else's perspective.  I'm using slush's pool, and his proxy; I've compiled on a fresh Linux install (I've also tried it on Windows, and received about the same results).  From many comments on this thread, I'm now using this string to run the proxy:  "/opt/slush0-stratum-mining-proxy-17d3226/mining_proxy.py -o stratum.bitcoin.cz -p 3333 -gp 8332".

The proxy command I am using on both windows and linux is

mining_proxy.py -q

thats for slushs pool (bitcoin.cz) and the -q is only to shut the verbage off

if you run the simplest command line you are eliminating any potential issues with switch settings

At worst it will only confirm that the settings are correct

[babaji.ca]

I too, have to wonder if these cubes are screwed... I've been struggling to get mine over 300Mhps.

I've used this thread as my guide for installation and troubleshooting.  Now I've exhausted what I think should be looked at... I'd like to get someones else's perspective.  I'm using slush's pool, and his proxy; I've compiled on a fresh Linux install (I've also tried it on Windows, and received about the same results).  From many comments on this thread, I'm now using this string to run the proxy:  "/opt/slush0-stratum-mining-proxy-17d3226/mining_proxy.py -o stratum.bitcoin.cz -p 3333 -gp 8332".

The proxy command I am using on both windows and linux is

mining_proxy.py -q

thats for slushs pool (bitcoin.cz) and the -q is only to shut the verbage off

if you run the simplest command line you are eliminating any potential issues with switch settings

At worst it will only confirm that the settings are correct

you should consider adding the switch -rt to the slush command line, it will allow it to increase the diff size greater than 1, it may run more efficiently with a higher diff level. I think when I run slush's proxy with that command the cubes push it to a diff level of 3, when I run bfgminer as a proxy it ends up 'auto-adjusting' the difficulty level all the way up to 32.

i actually find bfgminer a more efficient proxy, whether or not this is due to the far greater diff levels, i am not sure., but i can tell you it uses a hell of a lot less cpu than slushes. As a matter of fact on the RAS pi i could only run 1.5 cubes because the slush proxy bogged down the raspi so bad, it couldnt get better than about 15ghs on the second cube. CPU was pinned at about 98%  BFG on the other hand runs all three of my cubes at full speed never breaking a sweat, with a cpu load of under 10%.

those of you with poor running cubes may want to try bfgminer's proxy...

[ksami]

Perfect!  Glad to be able to help, and (sort of) glad my network problem wasn't a one-off.  I had been wondering if my house was just plain electrically screwed-up.    Anyway, great news - now enjoy those BTC!

Thank you for your help I appreciate When I connect my 2 android phones to WiFi, the performance drops down like crazy... Do you have any trick ? I don't have any option of QoS (Quality of Service)...  

I'm actually not familiar with android phones, but I'd imagine there might be a QoS setting in there somewhere.  But, what I was talking more about would be QoS settings in your home WiFi router(s).  You might have some luck just turning that off.  Where it is on your routers depends on the interface; I wouldn't know where to look on yours - you'd just have to log in with admin access and go 'xploring, sorry.

Cubes and Blades are handshaking-hogs with all the getworks they trade, and my guess is that anything that causes retransmits or pauses throws them for a loop.  A different brand might help, but I wouldn't be sure.

OK Thanks

[ksami]

That's just for the management interface, I switched it to port 80 so it'd be the regular http port.  The cube communicates to the stratum proxy via port 8332.

*I will try it just in case, I'll switch the port back to 8000 and refresh.

*Result was no change to performance.

Is it "Long Poll: inactive" all the time ?

[Apteryx]

you should consider adding the switch -rt to the slush command line, it will allow it to increase the diff size greater than 1, it may run more efficiently with a higher diff level. I think when I run slush's proxy with that command the cubes push it to a diff level of 3, when I run bfgminer as a proxy it ends up 'auto-adjusting' the difficulty level all the way up to 32.

On windows with the RT switch set I was getting a Diff of between 25 and 33. On the Raspberry, without the -rt switch set it went up to 56 initially then dropped back to 28. Not sure what it is running at now, I can't check atm, process is running in the background, not sure how I would switch to it ( I haven't done anything in Unix  since the late 80's and I don't recall Linux being out there then)

[otsaku]

even weirder, on bitminter I see my cube hashing at 26.9

in the web interface on the cube it shows 7.7 ...

Update:

The 400 watt psu blew, went back to the 550 expecting 5ghs but it's running at 25ghs.

[Shaker242]

Have you tried running it using BFGminer as a proxy. You have to have all the right dependencies when you build it. Namely libevent and libhttpd. luke jr's big long readme page about building a version of bfgminer.  https://github.com/luke-jr/bfgminer  (my ubuntu did not have the required versions of certain packages that were new enough to build it proxu support, but my rasberry pi's rasbian distro did) i find it to work better than slush' proxy,

You can also try connecting directly to eligius' pool, using gbt connection it may be better than nothing for the time being. I was able to run about 2.3 GH/s connected directly there without a proxy. maybe set it up as your 'b' address so you can toggle back and forth between it and your local proxy until you get things worked out locally. It may also tell you something about your cube or network (if things dont improve.) 

address gbt.mining.eligius.st
port 9337

(took me a bunch of tries to get it working just now, and actually its only minning at about 2300 MH/s) I got a bunch of zeros instead of mining numbers it leads me to believe you have network issues) can you try different cables, switches etc)

I have not tried BFGminer, as I happens I download it yesterday and will try that next.
* I have replaced the network cable and also moved it to a different port on my switch; thinking it was port related. 

Here are my port stats:

  Name  :                                                                 
  Link Status     : Up 
  Totals (Since boot or last clear) :                                   
   Bytes Rx        : 1,258,989,261      Bytes Tx        : 949,835,232       
   Unicast Rx      : 225,875,466        Unicast Tx      : 210,432,192       
   Bcast/Mcast Rx  : 79,453,505         Bcast/Mcast Tx  : 27,879,128       
  Errors (Since boot or last clear) :                                   
   FCS Rx          : 1                  Drops Rx        : 0                 
   Alignment Rx    : 0                  Collisions Tx   : 617               
   Runts Rx        : 0                  Late Colln Tx   : 0                 
   Giants Rx       : 0                  Excessive Colln : 0                 
   Total Rx Errors : 8                  Deferred Tx     : 722               
  Rates (5 minute weighted average) :
   Total Rx  (bps) : 10792              Total Tx  (bps) : 17360     
   Unicast Rx (Pkts/sec) : 0            Unicast Tx (Pkts/sec) : 0         
   B/Mcast Rx (Pkts/sec) : 0            B/Mcast Tx (Pkts/sec) : 1         
   Utilization Rx  : 00.10 %            Utilization Tx  : 00.17 %

This is 10MB/HDX so there will likely be some Collisions, but they're not increasing...

Thank you

[Shaker242]

I compiled BFGminer on my Linux server... here is the output:

 bfgminer version 3.9.0 - Started: [2014-01-05 12:40:57] - [  0 days 00:05:26]
 [M] anage devices [P] ool management [ S ] ettings [D] isplay options  [H] elp [Q] uit
 Connected to stratum.bitcoin.cz diff 1 with stratum as user BIT242.CUBE1A
 Block: ...29e9a698 #278786  Diff:1.42G (10.15Ph/s)  Started: [12:46:16]
 ST:2  F:0  NB:3  AS:0  BW:[ 48/ 10 B/s]  E:1.39  I: 2.55uBTC/hr  BS:45
 0            |  0.00/106.0/172.3Mh/s | A:11 R:0+0(none) HW:3/ 19%
--------------------------------------------------------------------------------
 PXY 0:       | SICK /106.0/172.3Mh/s | A:11 R:0+0(none) HW:3/ 19%
--------------------------------------------------------------------------------
 [2014-01-05 12:40:56] Waiting for devices; press 'M+' to add, or 'Q' to quit
 [2014-01-05 12:40:56] Probing for an alive pool
 [2014-01-05 12:40:57] Pool 0 http://stratum.bitcoin.cz:3333 alive
 [2014-01-05 12:40:57] Network difficulty changed to 1.42G (10.15Ph/s)
 [2014-01-05 12:40:57] Stratum from pool 0 detected new block
 [2014-01-05 12:40:57] Pool 0 is hiding block contents from us
 [2014-01-05 12:40:57] HTTP server listening on port 8332
 [2014-01-05 12:41:23] Stratum from pool 0 requested work update
 [2014-01-05 12:41:23] Stratum from pool 0 requested work update
 [2014-01-05 12:41:25] Accepted 4318ff57 PXY 0  Diff 3/3
 [2014-01-05 12:41:26] Accepted 159c20a9 PXY 0  Diff 11/1
 [2014-01-05 12:41:26] Accepted ff3f7022 PXY 0  Diff 1/1
 [2014-01-05 12:41:27] Accepted a520bdbe PXY 0  Diff 1/1
 [2014-01-05 12:41:27] Accepted a78bb9b6 PXY 0  Diff 1/1
 [2014-01-05 12:41:27] Accepted a9ac77ae PXY 0  Diff 1/1
 [2014-01-05 12:41:28] Accepted 3a4258bf PXY 0  Diff 4/1
 [2014-01-05 12:41:28] Accepted 86db63d1 PXY 0  Diff 1/1
 [2014-01-05 12:41:29] Accepted 05af7561 PXY 0  Diff 45/1
 [2014-01-05 12:41:29] Accepted fd7f4ee7 PXY 0  Diff 1/1
 [2014-01-05 12:41:29] Accepted 50feeb32 PXY 0  Diff 3/1
 [2014-01-05 12:41:53] Stratum from pool 0 requested work update
 [2014-01-05 12:42:23] Stratum from pool 0 requested work update
 [2014-01-05 12:42:29] PXY 0: Idle for more than 60 seconds, declaring SICK!
 [2014-01-05 12:42:53] Stratum from pool 0 requested work update
 [2014-01-05 12:43:07] Stratum from pool 0 detected new block
 [2014-01-05 12:43:09] Stratum from pool 0 requested work update
 [2014-01-05 12:43:37] Stratum from pool 0 requested work update
 [2014-01-05 12:44:07] Stratum from pool 0 requested work update

I'm not sure what SICK means yet, but you can see it's delivering 172Mhps.

[zeuzzz]

Anyone else here have an issue with changing the clock from low to high?

Using slush's pool I can cruise along fine at 30,000 Mh/s but as soon as I try to change the clock speed to high and click the reset button I get all x's, ie,

ASIC_01-16: x x x x x x x x x x x x x x x x
ASIC_17-32: x x x x x x x x x x x x x x x x
ASIC_33-48: x x x x x x x x x x x x x x x x
ASIC_49-64: x x x x x x x x x x x x x x x x
ASIC_65-80: x x x x x x x x x x x x x x x x
ASIC_81-96: x x x x x x x x x x x x x x x x

M_01-16: 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
M_17-32: 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
M_33-48: 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
M_49-64: 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
M_65-80: 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
M_81-96: 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000

Jobs:0000000000 Accepted:0000000000 Rejected:0000000000 (0:0) F1 F2 F3
MHS:00000 Utility:000 Efficieny:000.00%

Works absolutely fine until I try to overclock it, it showed this a few times but usually just fails with all x's now:

ASIC_01-16: O O O O O O O O O O O O O O O O
ASIC_17-32: O O O O O O O O O O O O O O O O
ASIC_33-48: O O O O O O O O O O O O O O O O
ASIC_49-64: O O O O O O O O O O O O O O O O
ASIC_65-80: O O O O O O O O O O O O O O O O
ASIC_81-96: O O O O O O O O x  x  x x x  x  x  x

I've been hesitant to open it up as I can't see why just overclocking it would be a hardware issue, and I might be selling it, should I ?

[twib2]

I compiled BFGminer on my Linux server... here is the output:
....
I'm not sure what SICK means yet, but you can see it's delivering 172Mhps.

Sick just means something's not right.  Did you try my suggestion for bfgminer with these, in which you point the second instance of pool address (and/or port) to some device:port that is NOT running a stratum proxy?

My guess is that will fix your "SICK" finding and then it'll run long enough for you to find the actual hashrate.

[twib2]

I've been hesitant to open it up as I can't see why just overclocking it would be a hardware issue, and I might be selling it, should I ?

It could indeed be a hardware issue since most of the times these heatsinks are loose, affecting cooling (bad cooling equals less headroom for OC'ing).  Also, some cards being not seated well can also affect cooling, same result.  Lastly, not fully seated cards can have poor connections with all sorts of problems leading to poor OCability (heat, electrical noise, etc).

So, yes, open it.  Carefully tighten all heatsink screws and seat the cards well and evenly, and then carefully reassemble (the LED and USB connector have to be watched closely when putting the face plate on).

If that doesn't fix your OC problems, be sure the ambient temperature is not too warm and you have good airflow around the devices AND that your powersupply is not the problem (numbers aren't the full story here, also has to do with the surge control, the rail stability, etc).

[Shaker242]

I compiled BFGminer on my Linux server... here is the output:
....
I'm not sure what SICK means yet, but you can see it's delivering 172Mhps.

Sick just means something's not right.  Did you try my suggestion for bfgminer with these, in which you point the second instance of pool address (and/or port) to some device:port that is NOT running a stratum proxy?

My guess is that will fix your "SICK" finding and then it'll run long enough for you to find the actual hashrate.

Thank you, I had forgotten about that... I've now added it to my configuration.

[daddyfatsax]

The only proxy that I have been able to get the cubes hashing at 38 GH/s is Slush's. When I run the Bfgminer proxy, I only get about 32 GH/s per cube on high clock. Also when using Bfgminer, long poll is inactive.

[Shaker242]

I compiled BFGminer on my Linux server... here is the output:
....
I'm not sure what SICK means yet, but you can see it's delivering 172Mhps.

Sick just means something's not right.  Did you try my suggestion for bfgminer with these, in which you point the second instance of pool address (and/or port) to some device:port that is NOT running a stratum proxy?

My guess is that will fix your "SICK" finding and then it'll run long enough for you to find the actual hashrate.

Thank you, I had forgotten about that... I've now added it to my configuration.

Things are starting to look better now... I'm getting a lot more activity on the cube.

M_01-16: 060 010 070 050 050 040 000 070 060 030 101 040 111 050 101 141
M_17-32: 020 040 141 060 000 040 000 151 080 010 000 040 070 070 040 030
M_33-48: 020 101 030 080 101 030 010 070 010 030 010 080 070 030 060 040
M_49-64: 040 111 080 040 030 070 030 000 020 020 000 030 020 030 030 000
M_65-80: 030 141 070 040 020 020 010 030 020 040 070 000 060 111 000 000
M_81-96: 050 080 000 101 010 020 020 000 010 010 040 020 010 080 020 010
Jobs:0000000665 Accepted:0000000423 Rejected:0000000025 (3:1) F1 F2 F3
MHS:04279 Utility:058 Efficieny:063.60%
Started before: 0d,00h,07m,14s
Current pool: 10.242.130.200 (A)
Switch mode: Primary/Backup
Clock selected: Low
Long Poll: active, LP requests: 4

and LP are working... I think you're on to something

[zeuzzz]

I've been hesitant to open it up as I can't see why just overclocking it would be a hardware issue, and I might be selling it, should I ?

It could indeed be a hardware issue since most of the times these heatsinks are loose, affecting cooling (bad cooling equals less headroom for OC'ing).  Also, some cards being not seated well can also affect cooling, same result.  Lastly, not fully seated cards can have poor connections with all sorts of problems leading to poor OCability (heat, electrical noise, etc).

So, yes, open it.  Carefully tighten all heatsink screws and seat the cards well and evenly, and then carefully reassemble (the LED and USB connector have to be watched closely when putting the face plate on).

If that doesn't fix your OC problems, be sure the ambient temperature is not too warm and you have good airflow around the devices AND that your powersupply is not the problem (numbers aren't the full story here, also has to do with the surge control, the rail stability, etc).

Thanks, I just opened up the front and the majority of the cards were not seated evenly in the bottom connectors or top rails ... I pushed each one down into their positions far more squarely. I also noticed when I opened it that the main board they all sit on it bent down in the middle as if pressure has been applied too hard from the top, anyone else notice this?

Even so after pushing all cards better into their fittings and retrying in high clock mode I only very briefly got this before getting another completely x'd out reading:

ASIC_01-16: x x x x x x x x x x x x x x x x
ASIC_17-32: x x x x x x x x x x x x x x x x
ASIC_33-48: x x x x x x x O x x x x x O x x
ASIC_49-64: x O x O x x x x x x x x O O x x
ASIC_65-80: x O x x O x x x x x O O O O O O
ASIC_81-96: x x x x x x x x x x x x x x x x

M_01-16: 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
M_17-32: 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
M_33-48: 000 000 000 000 000 000 000 000 000 000 000 000 000 798 000 000
M_49-64: 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
M_65-80: 000 000 000 000 000 000 000 000 000 000 000 000 399 000 000 000
M_81-96: 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000

Jobs:0000000056 Accepted:0000000003 Rejected:0000000000 (0:0) F1 F2 F3
MHS:01197 Utility:016 Efficieny:005.35%

It still works in low mode though ...

Where exactly are the heatsinks?

[ksami]

Anyone else here have an issue with changing the clock from low to high?

I have absolutely the same issue...

[TheWoodser]

Anyone else here have an issue with changing the clock from low to high?

I have absolutely the same issue...

I have not read the other posts but....Once you change the Clock speed, you have to click the "Update/Restart" button. 

if you hit the "Refresh" button, it will revert back to "Low"

Woodser

[Shaker242]

I compiled BFGminer on my Linux server... here is the output:
....
I'm not sure what SICK means yet, but you can see it's delivering 172Mhps.

Sick just means something's not right.  Did you try my suggestion for bfgminer with these, in which you point the second instance of pool address (and/or port) to some device:port that is NOT running a stratum proxy?

My guess is that will fix your "SICK" finding and then it'll run long enough for you to find the actual hashrate.

Thank you, I had forgotten about that... I've now added it to my configuration.

Things are starting to look better now... I'm getting a lot more activity on the cube.

M_01-16: 060 010 070 050 050 040 000 070 060 030 101 040 111 050 101 141
M_17-32: 020 040 141 060 000 040 000 151 080 010 000 040 070 070 040 030
M_33-48: 020 101 030 080 101 030 010 070 010 030 010 080 070 030 060 040
M_49-64: 040 111 080 040 030 070 030 000 020 020 000 030 020 030 030 000
M_65-80: 030 141 070 040 020 020 010 030 020 040 070 000 060 111 000 000
M_81-96: 050 080 000 101 010 020 020 000 010 010 040 020 010 080 020 010
Jobs:0000000665 Accepted:0000000423 Rejected:0000000025 (3:1) F1 F2 F3
MHS:04279 Utility:058 Efficieny:063.60%
Started before: 0d,00h,07m,14s
Current pool: 10.242.130.200 (A)
Switch mode: Primary/Backup
Clock selected: Low
Long Poll: active, LP requests: 4

and LP are working... I think you're on to something

I am now getting 470Mhps... I couldn't see any stats on Eligius.  Now I've setup a second proxy service to slush's pool and using a second worker. 

*currently
Login   Password   Found blocks   Current shares   Score   Last share at   Mhash/s*
BIT242.CUBE1A   nopass   0   2146   1265863.8412   0 minutes   539.7   
BIT242.CUBE1B   nopass   0   234   698299.0261   0 minutes   58.849