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

[zeuzzz]

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

I'm aware of this, the problem only occurs once I have hit the restart button ... my o's turn to x's and my mining software stops mining.

EDIT: Hmm, interesting, now it has stayed in high clock mode and is mining, but has half a row of x's and less than half the hashing power of low clock mode:

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: x x x x x x x x O O O O O O O O

M_01-16: 423 317 000 000 423 000 000 000 052 158 000 000 687 105 000 000
M_17-32: 529 211 052 000 211 264 000 158 000 634 000 000 105 634 000 000
M_33-48: 476 317 000 000 211 264 105 105 264 105 000 000 476 740 000 211
M_49-64: 317 158 000 000 158 476 052 000 158 211 000 158 317 000 000 000
M_65-80: 529 052 000 000 634 529 000 105 052 105 000 000 317 423 000 000
M_81-96: 000 000 000 000 000 000 000 000 687 105 000 052 529 052 000 000

Jobs:0000000546 Accepted:0000000273 Rejected:0000000000 (5:1) F1 F2 F3
MHS:14442 Utility:197 Efficieny:050.00%


Is it advisable to take the back panel and fan off to check the cards are seated correctly from the back? I'm worried of breaking the PCI-E or ethernet connectors ... and my panels simply do not slide out of the front like they should ...

[daddyfatsax]

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

I'm aware of this, the problem only occurs once I have hit the restart button ... my o's turn to x's and my mining software stops mining.

EDIT: Hmm, interesting, now it has stayed in high clock mode and is mining, but has half a row of x's and less than half the hashing power of low clock mode:

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: x x x x x x x x O O O O O O O O

M_01-16: 423 317 000 000 423 000 000 000 052 158 000 000 687 105 000 000
M_17-32: 529 211 052 000 211 264 000 158 000 634 000 000 105 634 000 000
M_33-48: 476 317 000 000 211 264 105 105 264 105 000 000 476 740 000 211
M_49-64: 317 158 000 000 158 476 052 000 158 211 000 158 317 000 000 000
M_65-80: 529 052 000 000 634 529 000 105 052 105 000 000 317 423 000 000
M_81-96: 000 000 000 000 000 000 000 000 687 105 000 052 529 052 000 000

Jobs:0000000546 Accepted:0000000273 Rejected:0000000000 (5:1) F1 F2 F3
MHS:14442 Utility:197 Efficieny:050.00%


Is it advisable to take the back panel and fan off to check the cards are seated correctly from the back? I'm worried of breaking the PCI-E or ethernet connectors ... and my panels simply do not slide out of the front like they should ...

I have only taken them apart from the back. I have had 2 fuses melt and taken 2 of my cubes apart.

[zeuzzz]

Ta just going to take the back panel off, by deduction though im fairly certain this is a card mounting issue as I noticed that I was getting eight x's on the right before I pushed the front of the card down, now I've pushed the front down the x's are on the left, so it looks as if I've pushed in the front eight at the expense of disconnecting the back eight by pivoting them round the middle

[zeuzzz]

Hmm nope the back of each card was in fine and they all turn to x's after a few second of it being on in high clock mode, still get a eight x's for a few seconds on the bottom row (ASIC_81-96) before they all eventually turn into x's and it fails completely.

With the front and back off the chips slid out nicely though so I could get a good look inside.

[TheWoodser]

Is it advisable to take the back panel and fan off to check the cards are seated correctly from the back? I'm worried of breaking the PCI-E or ethernet connectors ... and my panels simply do not slide out of the front like they should ...

I took the front and back panels of mine off before I powered it up the first time.  Just make sure not to put too much pressure on the fan wiring.

My main board was unseated from the grooves in the case and three of the six cards were unseated....All 6 were out of the case grooves..

Woodser

[twib2]

Where exactly are the heatsinks?

They are the big black aluminum finned plates on one side of each of the blades.  They have 4 mounting screws, one in each of the four corners, that screw into the black plate from the pcb side.

[twib2]

Wow, it looks like there's more than a little confusion on how far to take it all apart.  Here's the rundown a bit more explicitlly.

- Take the fuse off
- Take both the back and front covers off
- Disconnect the power to the front fan
- slide the whole board-and-blade assembly out either the front or the back (either is fine, just make sure you remember which is front and back or you won't be able to interlock multiple cubes anymore)
- Take each blade off and tighten all 4 heatsink screws holding the aluminum plate side of the blade (make sure you remember the alignment of each blade)
- Reinsert each blade firmly and evenly
- Slide the whole assembly back into the case, taking care that the grooves for the mainboard and the blades are aligned properly.  If they are, it should all slide in easily.
- Reassemble, taking care to ensure that the LED and the USB connector fit easily through the front plate, and don't forget to hook the fan back up.  Then put the fuse back on.
- Hook everything back up and restart.

You can now rule out misalignment and loose heatsinks.

The alignment problem is likely not so much an assembly problem as it is a shipping (and design) problem.  Since the bottom mainboard has no support under it, it is free to bow during stress, like rough handling during shipping.  This can allow blades to come out of their grooves and loosen.  Not good.  Care in handling after aligning things is all it should take, but if you're really concerned, one might consider putting some sort of non-conductive support under the mainboard as long as it does not impede airflow or add more stress to the assembly.

[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      

I now got off the proxies all together and using Eligius only direct via the GetWork settings... looks like it's getting 6Ghps now.

   Hashrate Average   Weighted Shares   12 hours   0.00 kh/s   0   3 hours   0.00 kh/s   0   22.5 minutes   0.00 kh/s   0   256 seconds   4,227.86 Mh/s   252   128 seconds   6,442.45 Mh/s   192

[zeuzzz]

Wow, it looks like there's more than a little confusion on how far to take it all apart.  Here's the rundown a bit more explicitlly.

- Take the fuse off
- Take both the back and front covers off
- Disconnect the power to the front fan
- slide the whole board-and-blade assembly out either the front or the back (either is fine, just make sure you remember which is front and back or you won't be able to interlock multiple cubes anymore)
- Take each blade off and tighten all 4 heatsink screws holding the aluminum plate side of the blade (make sure you remember the alignment of each blade)
- Reinsert each blade firmly and evenly
- Slide the whole assembly back into the case, taking care that the grooves for the mainboard and the blades are aligned properly.  If they are, it should all slide in easily.
- Reassemble, taking care to ensure that the LED and the USB connector fit easily through the front plate, and don't forget to hook the fan back up.  Then put the fuse back on.
- Hook everything back up and restart.

You can now rule out misalignment and loose heatsinks.

The alignment problem is likely not so much an assembly problem as it is a shipping (and design) problem.  Since the bottom mainboard has no support under it, it is free to bow during stress, like rough handling during shipping.  This can allow blades to come out of their grooves and loosen.  Not good.  Care in handling after aligning things is all it should take, but if you're really concerned, one might consider putting some sort of non-conductive support under the mainboard as long as it does not impede airflow or add more stress to the assembly.

^ Thanks a bunch, that helped a lot! I just opened it all up again and took each blade out, and a good percentage of the heatsinks screws were loose, so I tightened all four up on each blade and powered back on; unfortunately it's the same.

Every blade works in low clock mode.

As soon as I switch to high clock and click reset they turn to x's, sometimes I get a few o's momentarily, but eventually they revert to x's.

Clicking clock mode back to low does not work unless I power off/on the PSU again.

Once the power has been turned on/off it mines at 32 gh/s in low clock mode no problems.

[ksami]

^ Thanks a bunch, that helped a lot! I just opened it all up again and took each blade out, and a good percentage of the heatsinks screws were loose, so I tightened all four up on each blade and powered back on; unfortunately it's the same.

Every blade works in low clock mode.

As soon as I switch to high clock and click reset they turn to x's, sometimes I get a few o's momentarily, but eventually they revert to x's.

Clicking clock mode back to low does not work unless I power off/on the PSU again.

Once the power has been turned on/off it mines at 32 gh/s in low clock mode no problems.

Same problem here ! I saw in an earlier post, that you had to test a blade one by one in high clock mode, when you insert the blade that fails the high clock then this is it !

[Shaker242]

My average hash rate is now 14.20Ghps... so better without the use of a proxy.  This of course gives me a few other things I could start testing now to see if I can get it anywhere near 30Ghps. 

*just wanted to close this loop, I'm still working on it and hopefully I can get it figured out*

thanks for all the ideas and additional support.

[twib2]

Sorry you guys are having so much trouble.  I've set up 5 of these now and all problems have been one of three things:

• power supplies (regardless of numbers on the outside, one might work when it shouldn't and vice versa)
• network badness as I detailed before (bad player on the network: some device such as a router or android phone horking things up)
• physical setup of heatsinks/blades

All 5 worked in overclock just fine once I hammered out the power supplies, then I had to tweak the network.  Power supplies can't be stressed enough - if you don't get these right it's really hard to be sure you have the rest right.

I'm getting another in a few days so I'll let you know if there are any other problems and what I did to solve them.

[ksami]

Hi

I received my 2nd Cube, it's working in High clock mode without opening it, with the same 850W PSU (2 cubes on it) !

I think it's blades related issue...

http://img4.hostingpics.net/pics/221956614.png

[Shaker242]

Just a setup question, are you running two proxies?  (192.168.0.150 & 192.168.0.151)

Just wondering if that's the preferred method.

[ksami]

Just a setup question, are you running two proxies?  (192.168.0.150 & 192.168.0.151)

Just wondering if that's the preferred method.

Yep, I have setup 2 proxies in 2 different virtual machines !

You can do the same for testing

[Shaker242]

Just a setup question, are you running two proxies?  (192.168.0.150 & 192.168.0.151)

Just wondering if that's the preferred method.

Yep, I have setup 2 proxies in 2 different virtual machines !

You can do the same for testing

Do you also use two separate workers?

[ksami]

Do you also use two separate workers?

Yeah !

[Shaker242]

Do you also use two separate workers?

Yeah !

Okay, so check this out... I rebuilt two new VM's as Linux proxies using the E1000 interface, my original one was using VMNET3... now with the E1000 interface, the cube is working better.  I'll give it a few minutes as the hash rate is still increasing.  I'm not sure it's directly related to the E1000 though as I also tried this with a physical windows server.  Maybe having two proxies was the trick, no idea.  Just happy it's working better on slush's pool than it ever has before.

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 O O O O O O O O
M_01-16: 334 218 363 334 247 189 116 334 567 232 276 421 174 232 174 232
M_17-32: 290 319 697 334 392 421 363 348 378 276 218 348 276 276 305 334
M_33-48: 203 189 436 508 348 479 407 334 319 305 232 218 247 378 523 232
M_49-64: 348 348 276 159 334 392 407 159 203 421 174 348 421 465 130 290
M_65-80: 276 407 363 305 450 218 348 290 421 378 159 174 189 218 610 232
M_81-96: 159 334 189 392 610 334 290 348 378 363 392 392 247 305 334 276
Jobs:0000002250 Accepted:0000002110 Rejected:0000000005 (4:0) F1 F2 F3
MHS:30678 Utility:419 Efficieny:093.77%
Started before: 0d,00h,05m,02s
Current pool: 10.1.1.200 (A)
Switch mode: Primary/Backup
Clock selected: Low
Long Poll: active, LP requests: 1


**** In case someone want's to build a slush proxy on Ubuntu, this is what I did ****

My slush proxies..
Ubuntu Linux 12.04.3 LTS 64bit on ESXi 5.5
8GB VHD, 1GB RAM, 1CPU
NIC=E1000
*Post OS install where I just selected OpenSSH.

 1  apt-get update
 2  apt-get upgrade
 3  service apparmor stop
 4  update-rc.d -f apparmor remove
 5  apt-get install snmpd ntp build-essential unzip python-dev
 6 cd /opt
 7 wget https://github.com/slush0/stratum-mining-proxy/tarball/master
 8 tar zxf master
 9 wget https://pypi.python.org/packages/source/z/zope.interface/zope.interface-4.0.5.zip
10 unzip zope.interface-4.0.5.zip
11 cd zope.interface-4.0.5 ; python setup.py install
12 cd ../slush0-stratum-mining-proxy-17d3226 ; python setup.py install ; python setup.py install (I ran it twice)
13 ln -s /usr/local/bin/mining_proxy /usr/bin/mining_proxy
14 /usr/local/bin/mining_proxy.py -o stratum.bitcoin.cz -p 3333 -gp 8332 -q -i /var/run/miner.pid > /var/log/miner.log 2>&1 &

*step 14 runs it, outputs a process id and stdout to miner.log for monitoring.... to view the log while live just type "tail -f /var/log/miner.log"

I'm getting over 1Ghps and growing... still looks good.

If you want to make that a startup script.
 1 echo "/usr/local/bin/mining_proxy.py -o stratum.bitcoin.cz -p 3333 -gp 8332 -q -i /var/run/miner.pid > /var/log/miner.log 2>&1 &" > /etc/init.d/miner
 2 chmod +x /etc/init.d/miner
 3 update-rc.d miner defaults

Now reboot to verity it's running
 1 shutdown -r now
 2 ps -ef | grep miner (you should see the process string from the file)


* you'll also want to create a cronjob to dump out the miner.log file or you'll end up filling up your disk space... I just put this in a script and added it to cron to run every night at midnight.

#!/bin/bash
for x in `cat /var/run/miner.pid`
do
kill -9 $x
cat /dev/null > /var/log/miner.log
sh /etc/init.d/miner
done

** If you don't care about log files because your session is running as expected (like mine now), don't do the cron job entry and just export the output to /dev/null via this string instead of the one I supplied above:

"/usr/local/bin/mining_proxy.py -o stratum.bitcoin.cz -p 3333 -gp 8332 -i /var/run/miner.pid > /dev/null 2>&1 &"

I like to keep the PID so I can still write scripts against it if needed, if you don't want it... you can even shorten the script to:

"mining_proxy.py > /var/log/miner.log 2>&1 &"

Thanks and I hope my saga helps someone else... the E1000/ESXi 5.5/ ProCurve solution is the way to do btw.

[Shaker242]

F YEAH! after giving it a bit... my slush status is "38058.182Mhash/s"!

Now that's a solid solution!  Thanks for everyone's help!

[ksami]

F YEAH! after giving it a bit... my slush status is "38058.182Mhash/s"!

Now that's a solid solution!  Thanks for everyone's help!

Very nice I'm glad that you solved it