[Guide] Dogie's Comprehensive ASICMiner Blade Setup

[Vl4dim1r]

Alright, I've been hashing for a good several hours now, but my Blade seems to be averaging 8GH/s, I see all "O"s in the web config, so, from what I understand, all the chips are hashing. Is this normal for a board rated 10.7GH/s? Is the Rev 2.01 overclockable?

[xstr8guy]

Alright, I've been hashing for a good several hours now, but my Blade seems to be averaging 8GH/s, I see all "O"s in the web config, so, from what I understand, all the chips are hashing. Is this normal for a board rated 10.7GH/s? Is the Rev 2.01 overclockable?

Not normal.  No.

Where are you reading your hash rate?  If it's pool stats, most pools take a long time to average out your speed so they will read low at first.  If you are reading your hash rate from the Blade's configuration, maybe wait a bit and check after your Blade has run for a while.  I can't recall, but I think they may take a while to get up to speed.

And no, the new style blades aren't officially overclocking.  I'm sure some hardware hacker will come up with something soon though. 

[vesperwillow]

What's weird is, now all of the blades are mining at 10.7 ghash with the same configurations and I have no idea what caused the issue earlier.  Now I'm waiting to see if it comes up again.

If your blades are anything like mine, it will happen again. I agree it sounds like we're having similar issues, as are some others on the forums. Mine will get to 10.7, 11ish for a good couple hours, then switch proxies, and usually sit in the 300mh-2gh range for awhile, then switch and they die off and constantly reboot.

There's something not right in the firmware in my estimation. Sometimes, even on a cold boot, they just don't send packets out, and sometimes they do. Sometimes after not sending packets out for hours, they'll suddenly start. There's clearly a bug. It's happening on the new blades as well from what I've read in a few places, so it's not just a blade1 thing.

I have also noticed a pattern, if I disconnect blades from the network and let only one come online, generally speaking it works like a champ, 10-13gh. Within a minute or two of putting another blade on the same network (regardless of if its connecting to the same proxy/pool), they both go down. I continue to suspect something is up with how it's talking on the network.

Since this has occured, they seem most stable if they're allowed to hop between getwork and stratum (ie, put a getwork pool IP & a stratum proxy IP in the server line). If you force it to choose one or the other, it seems to simply fail to hash.

I see there's what appears to be a jtag/serial port on the NIC, I'm going to probe that tonight to see if I can find tty access.

[pidge]

Can I just say, that the latest bfgminer (released today) has native support for blades so a proxy may not be needed.  I've yet to try it myself, but it sounds promising.

The Windows binaries don't provide the http-port option, so I went to the trouble of building an Ubuntu workstation and building bfgminer 3.2 - and that didn't make a difference.  Or maybe I was to impatient with it?

The latest Win32 release of BFGMiner DOES support the http-port option.  Read the release notes.

The Windows binaries don't provide the http-port option,

Wrong.

Have either of you tried it?  I've downloaded version 3.2.0, both x86 and AMD64 builds.

Code:

C:\Program Files (x86)\BitCoin miner\bfgminer-3.2.0-win32>bfgminer -V
bfgminer 3.2.0

C:\Program Files (x86)\BitCoin miner\bfgminer-3.2.0-win32>bfgminer -o stratum.btcguild.com:3333 -O pjnield_5:1234 --http-port 8533

 [2013-09-20 23:13:18] bfgminer: --http-port: unrecognized option

the --http-port option is not listed in the help reported by bgfminer.exe, nor in the linux build, although the feature is s listed in the release notes, and instructions in README.ASIC.txt.

But it's accepted on the linux build I did, and runs quite happily, though the speed reported in Blade config page never seems to reach >10GH like it does with mining_proxy.

I'm confused!

[vesperwillow]

Regarding the 24v input discussion

I took a closeup of the power lane section of the blade, presuming the chip I'm focusing on is schematically what we're looking for. It's a buck controller (DC to DC step down converter, often used in dropping 12v computer power down to CPU levels).

Here is a closeup of the area:



It's a Sipex 6133 model, 5-24VDC input, handles up to 30A.

Here's one of several datasheet links/possibilities: http://www.alldatasheet.com/datasheet-pdf/pdf/173439/SIPEX/SP6133.html

More than likely 24VDC could be used, however I wouldn't want to simply try it without examining the circuit to ensure everything else could take more than 12. Most components are rated 13-400VDC but, you never know.

Hopefully that helps with the discussion.

[xyzzy099]

Can I just say, that the latest bfgminer (released today) has native support for blades so a proxy may not be needed.  I've yet to try it myself, but it sounds promising.

The Windows binaries don't provide the http-port option, so I went to the trouble of building an Ubuntu workstation and building bfgminer 3.2 - and that didn't make a difference.  Or maybe I was to impatient with it?

The latest Win32 release of BFGMiner DOES support the http-port option.  Read the release notes.

The Windows binaries don't provide the http-port option,

Wrong.

Have either of you tried it?  I've downloaded version 3.2.0, both x86 and AMD64 builds.

Code:

C:\Program Files (x86)\BitCoin miner\bfgminer-3.2.0-win32>bfgminer -V
bfgminer 3.2.0

C:\Program Files (x86)\BitCoin miner\bfgminer-3.2.0-win32>bfgminer -o stratum.btcguild.com:3333 -O pjnield_5:1234 --http-port 8533

 [2013-09-20 23:13:18] bfgminer: --http-port: unrecognized option

the --http-port option is not listed in the help reported by bgfminer.exe, nor in the linux build, although the feature is s listed in the release notes, and instructions in README.ASIC.txt.

But it's accepted on the linux build I did, and runs quite happily, though the speed reported in Blade config page never seems to reach >10GH like it does with mining_proxy.

I'm confused!

The windows support was added in the newest release - 3.2.1.  You need to update.  I have not tried it on Windows, so I can't personally vouch for how well it works there.  On Linux, my blades hash at a very consistent 10.7 GH/s each on Eligius via BFGMiner.

[vulgartrendkill]

Can I just say, that the latest bfgminer (released today) has native support for blades so a proxy may not be needed.  I've yet to try it myself, but it sounds promising.

The Windows binaries don't provide the http-port option, so I went to the trouble of building an Ubuntu workstation and building bfgminer 3.2 - and that didn't make a difference.  Or maybe I was to impatient with it?

The latest Win32 release of BFGMiner DOES support the http-port option.  Read the release notes.

The Windows binaries don't provide the http-port option,

Wrong.

Have either of you tried it?  I've downloaded version 3.2.0, both x86 and AMD64 builds.

Code:

C:\Program Files (x86)\BitCoin miner\bfgminer-3.2.0-win32>bfgminer -V
bfgminer 3.2.0

C:\Program Files (x86)\BitCoin miner\bfgminer-3.2.0-win32>bfgminer -o stratum.btcguild.com:3333 -O pjnield_5:1234 --http-port 8533

 [2013-09-20 23:13:18] bfgminer: --http-port: unrecognized option

the --http-port option is not listed in the help reported by bgfminer.exe, nor in the linux build, although the feature is s listed in the release notes, and instructions in README.ASIC.txt.

But it's accepted on the linux build I did, and runs quite happily, though the speed reported in Blade config page never seems to reach >10GH like it does with mining_proxy.

I'm confused!

Thats possibly because the feature was added for 3.2.1?  I thought that was the case.

[vesperwillow]

The windows support was added in the newest release - 3.2.1.  You need to update.  I have not tried it on Windows, so I can't personally vouch for how well it works there.  On Linux, my blades hash at a very consistent 10.7 GH/s each on Eligius via BFGMiner.

What build of linux do you use it on? I couldn't get the dependancy installed on ubuntu 12.04, the latest build they had was 0.9.27 but BFG required 0.9.5x

[pidge]

I have a fresh build of Ubuntu 13.0.4.  I'll spare you the details of wrangling with apt-get etc :|

[pidge]

The windows support was added in the newest release - 3.2.1.  You need to update.  I have not tried it on Windows, so I can't personally vouch for how well it works there.  On Linux, my blades hash at a very consistent 10.7 GH/s each on Eligius via BFGMiner.

Ahhh!  I'll give it a crack.

[xyzzy099]

The windows support was added in the newest release - 3.2.1.  You need to update.  I have not tried it on Windows, so I can't personally vouch for how well it works there.  On Linux, my blades hash at a very consistent 10.7 GH/s each on Eligius via BFGMiner.

What build of linux do you use it on? I couldn't get the dependancy installed on ubuntu 12.04, the latest build they had was 0.9.27 but BFG required 0.9.5x

I'm using Ubuntu 13.04.

[pidge]

I've given it a crack, it works.

One thing I've noticed is that the userid given in the blade configuration is used to distinguish between the blades, not the blade IP address.

Oh, and something I threw together to help watch the blades side-by-side:

Code:

<HTML>
<HEAD>
</HEAD>
<BODY>
<TABLE>
<TR>
<TD><iframe id=150 height=430 width=350 src="http://192.168.0.150:8000/"></iframe></TD>
<TD><iframe id=151 height=430 width=350 src="http://192.168.0.151:8000/"></iframe></TD>
<TD><iframe id=152 height=430 width=380 src="http://192.168.0.152:8000/"></iframe></TD>
</TR>
<TR>
<TD style="text-align:center;"><button onclick="document.getElementById('150').src='http://192.168.0.150:8000/';">Reload</button></TD>
<TD style="text-align:center;"><button onclick="document.getElementById('151').src='http://192.168.0.151:8000/';">Reload</button></TD>
<TD style="text-align:center;"><button onclick="document.getElementById('152').src='http://192.168.0.152:8000/';">Reload</button></TD>
</TR>
</TABLE>
</BODY>
</HTML>

The layout can cope with 4, maybe 5 wide on an HD monitor.  Add another row for 8 or 10
Replace the IP addresses with your IP addresses, the iframe IDs need to be unique and are ised to link the reload button to the correct iframe
If you click on the update/restart button in a config page, click on the reload button underneath to go back to the config page
Adding a reload time for each should be straightforward

[xyzzy099]

I've given it a crack, it works.

One thing I've noticed is that the userid given in the blade configuration is used to distinguish between the blades, not the blade IP address.

Oh, and something I threw together to help watch the blades side-by-side:

Code:

<HTML>
<HEAD>
</HEAD>
<BODY>
<TABLE>
<TR>
<TD><iframe id=150 height=430 width=350 src="http://192.168.0.150:8000/"></iframe></TD>
<TD><iframe id=151 height=430 width=350 src="http://192.168.0.151:8000/"></iframe></TD>
<TD><iframe id=152 height=430 width=380 src="http://192.168.0.152:8000/"></iframe></TD>
</TR>
<TR>
<TD style="text-align:center;"><button onclick="document.getElementById('150').src='http://192.168.0.150:8000/';">Reload</button></TD>
<TD style="text-align:center;"><button onclick="document.getElementById('151').src='http://192.168.0.151:8000/';">Reload</button></TD>
<TD style="text-align:center;"><button onclick="document.getElementById('152').src='http://192.168.0.152:8000/';">Reload</button></TD>
</TR>
</TABLE>
</BODY>
</HTML>

The layout can cope with 4, maybe 5 wide on an HD monitor.  Add another row for 8 or 10
Replace the IP addresses with your IP addresses, the iframe IDs need to be unique and are ised to link the reload button to the correct iframe
If you click on the update/restart button in a config page, click on the reload button underneath to go back to the config page
Adding a reload time for each should be straightforward

Nice, that is handy.  Thanks!

[vesperwillow]

FWIW for anyone following my discussion on the blades having hash/reboot/proxy issues, when my blades ARE working they're doing fabulously. Most are between 12.5-13.0 for awhile, I have one which is actually into the mid-upper 13's, knocking on the 14gh door.

That's when they're working.

It would be great if friedcat could give some diagnosis info in case the serial/jtag port on the board is actually readable.

[mdopro1]

My 4 blades are hashing fine but all 4 of them are switching server on the spot at 1 hour mark. I can't figure it out anymore, all is good yet switching servers.

[vesperwillow]

My 4 blades are hashing fine but all 4 of them are switching server on the spot at 1 hour mark. I can't figure it out anymore, all is good yet switching servers.

I've got one which is constantly restarting entirely, doesn't seem to be a pattern to it, sometimes it goes for hours, someitmes it goes for minutes. It's hovering in the 12-13gh range when it's working. It's binding to the stratum proxy and working like a champ, though I have a getwork IP as backup.

If I don't have the getwork IP in there and use 2 stratum proxy IPs (whether the same or each is different), it absolutely refuses to hash or connect to a server. The second I put a getwork IP in and restart it, it's fine, and does this "hash for awhile and then reboot" thing.

I'm eyeing another one right now, 3 hours of uptime in the mid 13gh range. Prior to that it ran about 6 hours at 13gh. Same situation, I have to have a getwork IP as one of the server IPs, otherwise it'll constantly reboot.

We are onto something here. Maybe it's affecting all of them but not everyone pays close attention.

[Vl4dim1r]

Alright, I've been hashing for a good several hours now, but my Blade seems to be averaging 8GH/s, I see all "O"s in the web config, so, from what I understand, all the chips are hashing. Is this normal for a board rated 10.7GH/s? Is the Rev 2.01 overclockable?

Not normal.  No.

Where are you reading your hash rate?  If it's pool stats, most pools take a long time to average out your speed so they will read low at first.  If you are reading your hash rate from the Blade's configuration, maybe wait a bit and check after your Blade has run for a while.  I can't recall, but I think they may take a while to get up to speed.

And no, the new style blades aren't officially overclocking.  I'm sure some hardware hacker will come up with something soon though. 

I've been mining for 19 hours now, and its still averaging 8GH/s, reading from both BFGminer and my pool stats.

[r00t$]

It looks like the link to the proxy executable for windows is down :-(

http://mining.bitcoin.cz/media/download/mining_proxy.exe

Anyone have another source?

Thanks.

[r00t$]

It looks like the link to the proxy executable for windows is down :-(

http://mining.bitcoin.cz/media/download/mining_proxy.exe

Anyone have another source?

Thanks.

It turns out I had a copy of it on my work laptop from a while back. My blade is up and hashing. Thanks dogie!

If you are trying to setup your new blade and are having problems with the proxy download site being down, shoot me a pm and I will send you a link to my Google drive :-)

[mdopro1]

I have now setup 4 proxies on 4 different computers, 2 of them connecting to one pool and the other two connecting to a different pool. Although my blades are still constantly switching servers on the hour mark, they are at least hashing well.