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

[dogie]

2) Yes, physically reverse the fan to reverse airflow direction. I'll clarify this.

Do you have any numbers on the hash rate increase?

~0.2-0.5GH increase depending on your ambient. Remember with 96 chips you only need a 2 MHz average increase for another .2GH. And if you look at the difference between M1-16 (worst cooling), and the other boards, its about -3 down.

[divinesnail01]

I'm going slightly nuts here, and would appreciate some additional assistance.

I'm running 3 cubes - 3rd one arrived about a week ago.  2 of them usually run at 38 (high clock) and one of them runs at 30 (low clock) because I don't like how the power leads heat up on that power supply, and I haven't bought a new one yet.

Last Thursday, I was showing 100GH/s at my pool - less than I expected, but reasonable.

Since then, I'm seeing what I consider to be really odd behavior in my proxy(ies).  Specifically, they will run with the usual scrolling display for 10 - 15 seconds, and then stop.  About 45 seconds later they'll start scrolling again.

I've tried Linux (Ubuntu 10.04 LTS and 12.04 LTS) on virtual machines on 2 different hosts.  I've actually lost count of how many iterations of linux machines I've tried.  I've tried Windows XP, Windows 7, and Windows 8 on three different machines - all of which have had the cubes running at 38-39 GH/s each in the past.  I've tried multi-homing the Linux virtual machines - one interface "outside" on the public internet, and the second interface "inside" for the cubes to connect to so as to bypass any congestion that my firewall might be adding.

I've been wanting to blame my ISP (Comcast business - no love lost there), so tonight I built an Ubuntu 12.04 LTS machine on an Amazon EC2 cloud instance, and it is doing the very same thing - running for 10 -15 seconds, and then pausing.  Here's the strange part - the proxy running on the local machine and the proxy running on the EC2 pause and restart at exactly the same time.

Say what!!!???!!!

So I'm officially stumped.

Tonight I'm down to about 13GH/s on the two "faster" cubes, and and about 12 on the slower one.  That's (almost?) not worth feeding electricity to.

I would be immensely appreciative of someone who has some experience with multiple cubes helping me to walk back through this.  I can't believe that it's connectivity issues with the pool - I'd be hearing about it in the forums, right?

Actually - let's explore that for a moment - anyone else here running multiple cubes through Comcast that can say "yea" or "nay" to connectivity issues to Slush?

Thanks in advance;

'snail

A follow up, and perhaps some help for someone else:

Really short version:  The more you can isolate these on the network the happier they'll be.

Short version:  There might actually be something to that "get the Androids off the network".  Running for 2 days now at above full rated speeds, just in time for the Slush pool to have a pretty good run of luck.  I'm currently showing 106GH/s on the pool - my theoretical maximum for 2 at 38 and one at 30.

Longer version:  I didn't think the Android issue would apply to me, as I don't use the wireless access point as my router, and the cubes and the wireless access point (and thus the Android machines) are on different network switches.  I was watching my network traffic and my bandwidth utilization, both of which were quite low, and so assumed that the problem MUST be the proxy talking to the pool.
Under the heading of "can always learn something new" however, I decided to test the theory, but knew that it would be easier to cut fingers off than to get all the Android devices off my network. 
So....   I took another older consumer level router that I wasn't using anymore, and connected it to my cable modem as a peer to my primary firewall (I have a pretty good internet connection that gives me some flexibility that not everyone would have).  I moved a "hardware" machine and the cubes to that network, set my IP addresses, and started mining.  The improvement was startling.  Almost immediately into the 35 range for the two faster ones, and over the next hour, tickling 39.  The slower one showed similar performance.  I then put a connection from unused network ports on my virtual hosts, and started 2 virtual machines up.  Set the cubes to the virtual machines for the proxy, shut down the "hardware" machine and let them run.  We're coming up on 48 hours since the last time I restarted the cubes for an IP address change, and the numbers are great.  I don't see them rotating between proxies, and so could probably get away with just one VM, but the 2nd one doesn't cost me anything.

Time to upgrade this poor power supply that came with the 3rd cube, and then add a 4th.  Don't tell my wife. 

As a side note:  The "proxy in the cloud" on the Amazon EC2 actually worked pretty well once I got the cubes isolated.  I'm getting a little bit better numbers with the local machines, but if I didn't have these hosts running 24/7/365 already anyway, I'd seriously consider getting the free Amazon account for a year, and letting them pay the electricity for the proxy.

Thanks for the help, and happy mining.

'snail

[dogie]

You can illiminate pool - > proxy -> pool pretty easily because of the output from the proxy. It tells you if it connects, if it can auth, and if it gets a work packet ready for mining.

[DanZaph]

Really short version:  The more you can isolate these on the network the happier they'll be.

Short version:  There might actually be something to that "get the Androids off the network".  Running for 2 days now at above full rated speeds, just in time for the Slush pool to have a pretty good run of luck.  I'm currently showing 106GH/s on the pool - my theoretical maximum for 2 at 38 and one at 30.

Longer version:  I didn't think the Android issue would apply to me, as I don't use the wireless access point as my router, and the cubes and the wireless access point (and thus the Android machines) are on different network switches.

The issue with Android is using IP addresses after the DHCP lease expires, not traffic. See ”DHCP client ignores lease time”: https://code.google.com/p/android/issues/detail?id=11236.

So, a good solution is to put the Android devices on a separate logical network. If the primary network is 192.168.1.x then create a second network such as 192.168.2.x (both with a net mask of 255.255.255.0). Unfortunately that means two routers.

Is this what you did with the second router?

[divinesnail01]

Really short version:  The more you can isolate these on the network the happier they'll be...

[snip]

Longer version:  I didn't think the Android issue would apply to me...

The issue with Android is using IP addresses after the DHCP lease expires, not traffic. See ”DHCP client ignores lease time”: https://code.google.com/p/android/issues/detail?id=11236.

So, a good solution is to put the Android devices on a separate logical network. If the primary network is 192.168.1.x then create a second network such as 192.168.2.x (both with a net mask of 255.255.255.0). Unfortunately that means two routers.

Is this what you did with the second router?

And that was exactly some of my reasoning for not worrying about the Androids:  Though on the same logical network, the Android device addresses were assigned in a different part of the address space than the addresses I was using for the cubes and the proxies; I have my DHCP leases set for 7 days; my DHCP server pings the address as it's being assigned to be sure that there isn't a "squatter" on the address before offering it.  It's pretty difficult for a lease to expire and create an address conflict under those circumstances.  Further, I saw the same behavior with the proxies in my DHCP space as I did with them assigned statically outside of the DHCP pool.

I haven't spent the time, and probably won't, to dive deeper into what's going on on the network, but I can say with some confidence that it's not an issue of IP address conflicts, unless the android devices are "making up" addresses to use elsewhere in the address space, and managing to do that without causing other devices to squawk about an address conflict.  Ultimately, however, that turns into a Quixotic discussion - there definitely IS something about having cubes on the same network with other devices, likely Androids, and the solution is the same regardless of the root cause: get them isolated from each other.

My solution has been to create a completely separate physical network.  I've used different IP addressing for that network, but since they aren't interconnected, it really doesn't matter.  It's a little bit of an extreme solution, but very effective.

[dogie]

Ive only seen it affect getwork based hardware that has to talk to another device on the network, everything else seems to be fine.

[thegoldbug]

After experiencing weeks of one of my two cubes shutting down for no apparent reason (sometimes it would run from 15 minutes to 2 days) I broke out the soldering iron last night and jumped those two solder points.  The problematic cube has been hashing away without any issues for 16 hours and 18 minutes.  This appears to have solved the problem of it dropping out (just the top green light on).


I don't have any Android appliances and I did try different power supplies, move the cubes to different locations in the house and garage, changing the IP address, pulling and re-seating boards, updated the mining_proxy software, etc.  Nothing worked for long.

Now if I could only get my one cube running back around 30Gh/s instead of the 12-15Gh/s range.  It used to work okay (nothing better than 30Gh/s).  I wonder if I should break out the soldering iron and jumper it?  Comments?

thanks

[dogie]

After experiencing weeks of one of my two cubes shutting down for no apparent reason (sometimes it would run from 15 minutes to 2 days) I broke out the soldering iron last night and jumped those two solder points.  The problematic cube has been hashing away without any issues for 16 hours and 18 minutes.  This appears to have solved the problem of it dropping out (just the top green light on).


I don't have any Android appliances and I did try different power supplies, move the cubes to different locations in the house and garage, changing the IP address, pulling and re-seating boards, updated the mining_proxy software, etc.  Nothing worked for long.

Now if I could only get my one cube running back around 30Gh/s instead of the 12-15Gh/s range.  It used to work okay (nothing better than 30Gh/s).  I wonder if I should break out the soldering iron and jumper it?  Comments?

thanks

What were the results of swapping the problem cube with the exact position and power of the other cube?

[thegoldbug]

The problem cube (when it ran, it runs at 30-32 Gh/s) behaved the same (would run for 5 minutes to almost two days) in all locations and with a 750watt and a 650watt power supply.  It behaved the same if switched the pools, if I changed the IP, if I changed the clock, etc.


The cube without the drop-out problem is the one that hashes slowly all processors are showing okay (no Xs) but only the first three boards are showing any hashing.   I'll take it apart and reseat the boards and check the heatsink screws.

thanks

[thegoldbug]

I pulled the cube apart, inspected and tightened the heat sink screws (just a little).  I swapped board 4 for board 6 (only the first 3 boards were hashing).

It's back online at LOW clock.  The first 3 boards are hashing well and board 4 has a few chips that are hashing and they are doing poorly, board 5 and 6 are all zeros for hashing but no boards are showing up as dead Xs.

Total hashing rate is 12,599.

I have to admit that my two cubes have been nothing but problems since day one.  Nice concept and good form factor but problems on the inside.

[dogie]

I pulled the cube apart, inspected and tightened the heat sink screws (just a little).  I swapped board 4 for board 6 (only the first 3 boards were hashing).

It's back online at LOW clock.  The first 3 boards are hashing well and board 4 has a few chips that are hashing and they are doing poorly, board 5 and 6 are all zeros for hashing but no boards are showing up as dead Xs.

Total hashing rate is 12,599.

I have to admit that my two cubes have been nothing but problems since day one.  Nice concept and good form factor but problems on the inside.

Remove any board which isnt working! It will only cause more damage if its dead.

[Isuearl]

FWIW I got a cube last week and have been running it off a 500w PSU, and found that the wires on the 6x PCIE plug got terribly hot....but the plug that I have running of 2 4 pin molex those wires are nice and cool.  yesterday I suddenly smelled the burning electronic smell, quickly shut off my cube and inspected it...found that the supplied fuse MELTED....was like WTF....pulled the boards out, everything was good, reinstalled the boards , replaced the fuse with another 30amp fuse, and now everything is working good and the wires on the 6x PCIE are much cooler....which leads me to believe that the stock fuse was the cause of my issues, It was forcing more current draw due to the resistance of the metal that was used in it....hence the hotter wires...
so what I wonder is what type of alloy did the manufacturer of the fuse use to cause such a higher resistance...
 my .02 cents is if your having issues with a PSU kicking off is try a different 30A fuse other than the stock one...

[DanZaph]

but the plug that I have running of 2 4 pin molex those wires are nice and cool

What does "2 4 pin molex" mean? The cube has two 6-pin power connectors. Each should have six wires.

which leads me to believe that the stock fuse was the cause of my issues, It was forcing more current draw due to the resistance of the metal that was used in it....hence the hotter wires...

No. The higher the resistance the lower the current. E=IR or transposed: I=E/R where I=current, E=voltage, R=resistance.

There are two main reasons a fuse will "blow".

1. The current is above the fuses limit, that is what fuses are designed to prevent. That would mean in this case that the Cube was drawing to much current, greater than 30a, and the fuse protected the Cube and/or power supply.

2. The fuse was defective.

[dogie]

but the plug that I have running of 2 4 pin molex those wires are nice and cool

What does "2 4 pin molex" mean? The cube has two 6-pin power connectors. Each should have six wires.

which leads me to believe that the stock fuse was the cause of my issues, It was forcing more current draw due to the resistance of the metal that was used in it....hence the hotter wires...

He means 2xmolex to 1xPCI-E cable

[Isuearl]

Dogie has it, that is what I meant 2xMolex to 1x PCI-E, and Dan, sorry for the misstatement, I do know that higher resistance causes lower current...what I was trying to say that the cube was trying to draw more Amps than what was necessary...but the fuse didn't blow, it just heated up, and since it was drawing at a higher Amperage, it was causing my PCI-E wires from the PSU to heat up to very disconcerting levels, but then the Stock fuse melted...luckily I was home and caught it in time before any damage could be done....
  I just replaced the stock fuse with a new 30 amp...now everything is running much cooler than before, and my error rate even went down...

[dogie]

Dogie has it, that is what I meant 2xMolex to 1x PCI-E, and Dan, sorry for the misstatement, I do know that higher resistance causes lower current...what I was trying to say that the cube was trying to draw more Amps than what was necessary...but the fuse didn't blow, it just heated up, and since it was drawing at a higher Amperage, it was causing my PCI-E wires from the PSU to heat up to very disconcerting levels, but then the Stock fuse melted...luckily I was home and caught it in time before any damage could be done....
  I just replaced the stock fuse with a new 30 amp...now everything is running much cooler than before, and my error rate even went down...

Sounds about right - its not uncommon for fuses to have a 90-95% yield rate. It is after all a rather iffy mechanism to begin with.

[brush242]

Dogie has it, that is what I meant 2xMolex to 1x PCI-E, and Dan, sorry for the misstatement, I do know that higher resistance causes lower current...what I was trying to say that the cube was trying to draw more Amps than what was necessary...but the fuse didn't blow, it just heated up, and since it was drawing at a higher Amperage, it was causing my PCI-E wires from the PSU to heat up to very disconcerting levels, but then the Stock fuse melted...luckily I was home and caught it in time before any damage could be done....
  I just replaced the stock fuse with a new 30 amp...now everything is running much cooler than before, and my error rate even went down...

Sounds about right - its not uncommon for fuses to have a 90-95% yield rate. It is after all a rather iffy mechanism to begin with.

Someone here on bitcointalk.org mentioned using some sort of 30A automotive(?) fuses as replacements, does anyone remember offhand the reason why? Maybe it's faster acting or something? I need to pick some up anyway, so I might as well get extra ones.

Thanks.

[Isuearl]

The reason they said automotive, is because the fuses are the blade type typically used for automotive electrical systems.  They are not specifically automotive, but that is where they are used the most....

[brush242]

The reason they said automotive, is because the fuses are the blade type typically used for automotive electrical systems.  They are not specifically automotive, but that is where they are used the most....

Okay, that makes sense to me. Of course it does, I have them in my car. I was under the impression that there was some little twist or a special kind of them. Maybe ones that go to 11?

Thank you.

[DanZaph]

The reason they said automotive, is because the fuses are the blade type typically used for automotive electrical systems.  They are not specifically automotive, but that is where they are used the most....

Okay, that makes sense to me. Of course it does, I have them in my car. I was under the impression that there was some little twist or a special kind of them. Maybe ones that go to 11?

Fuses: Actually they kind of do go to 11. Consider the fuses/circuit breakers in a typical US house are 15a, the Cube fuse is 30a, twice that. Automotive fuses are designed for high currents at low voltages, exactly what the cube needs. Additionally the connector the fuse plugs into is small, cheap and well tested in automotive usage.

Wire: As long as the coper does not melt the limiting factor is the insulation and the max temperature it can sustain. Many wires in close proximity such as in a cable or conduit reduces the dissipation of heat and the allowable current must be reduced. Warm wires do mean voltage loss but not necessarily a hazard. Personally I would up-size the wire gage if possible such that there was very little heating of the wires.