Topic: [Guide] Dogie's Comprehensive ASICMiner Cube Setup [HD] - page 87. (Read 187363 times)

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?

Looks like we have similar config going through guild.

I have the same / similar issue

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?

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.

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

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

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.

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

**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.

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.

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

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

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


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.

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.

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?

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

http://amzn.to/1bNDbaV

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.

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.

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

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