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

Latest update in my 30ghs quest.

My cx750m corsair came today. Swapped out the 550 and let it run for ten minutes til I checked the hashrate:


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: 321 433 282 282 355 253 448 331 404 277 350 370 287 346 248 355
M_17-32: 336 311 282 428 297 355 370 370 263 321 229 307 355 365 336 287
M_33-48: 365 341 311 414 302 375 316 370 341 380 292 321 399 204 355 394
M_49-64: 292 331 404 370 365 331 204 277 355 311 302 316 287 263 180 297
M_65-80: 253 346 350 238 272 360 263 277 229 287 243 263 238 141 112 175
M_81-96: 170 082 112 053 077 077 029 014 000 004 009 000 000 000 000 000
Jobs:0000005390 Accepted:0000005261 Rejected:0000000008 (0:4) F1 F2 F3
MHS:25639 Utility:350 Efficieny:097.60%
Started before: 0d,00h,15m,01s
Current pool: 192.168.1.105 (A)
Switch mode: Primary/Backup
Clock selected: Low
Long Poll: active, LP requests: 0


Absolutely no improvement.

If you look at the 6th blade there are chips with no activity.

I opened up the cube, re-checked the heatsinks and put the blades back in making sure that what was blade 1, with 100% working, though slow, chips was put in as blade 6.

Before the swap there were 3 000 chips on blade 6...

The corsair 550 gave me periodic hashrates of 35+ with out overclock. The longest of these was 6 hours.

My noname 400 that blew gave me a steady 31 before the end of it's life but still with 000 chips on the 6th blade.

So a couple of thoughts:

The 6th blade seat is faulty in some way.

The power coming out of the wall isn't constant or the ampage is too low.

I need a non wifi router for the cube to plug into.

i remember having trouble also, see if this works:

Type "ldconfig" to update the links

Hi, when i try to start bfg appears an error:

after a long struggle, what worked for me is on the cube's setting the dns to 192.168.2.1 same as my network, that's what I was missing. hope this helps someone else.

Replying to myself here, but the results may help others... The Raspberry Pi (MinePeon) with the http listener command would fall offline after every round, or at least the two I had seen- obviously unacceptable to leave it like that but short on time to find out why Minepeon was dropping off the network... I had to move the cube to another machine running Slush's proxy, now longpoll is displaying, efficiency is ~91% (and hopefully still climbing), but I still don't know what is up with my "X" chip.

Edit 2: Efficiency is at 97% running on Slush's proxy, but I've still got an "X" on one chip. I opened the unit up, tightened everything and re-seated, and also used the factory reset button. Should I just accept the "X" and learn to live with it?
I'm guessing it means I lose 333mh/s or something (hopefully) insignificant.

Okay, so I'm having a hellva time setting this rig up:
long story short: i'm getting 'pool 0 is hiding block contents from us'
and 'stratum from pool 0 requested work update' - over and over...

Its connecting to bitminter. and as far as I can tell, the problem appears to be the cube is not connecting to the proxy...
after reading this thread a few times over, I still can't seem to find the correct information.
(the port 8330 is set on the cube, as well as in bfg)

after finding the ip address via ifconfig (second line: inet addr:192 etc) i configured the cube to set pools to that address, (twice as instructed)

I am pulling my hair out here - as it seems like there's something obvious I'm missing!

yes i have noticed that it is missing longpoll support, but i (very unscientifically) still have found bfgminer to get me better hashing results at the pool despite the absence of longpoll support

but anyways the reason i am using bfgminer is that slush's proxy cannot handle more than one cube on a rasberry pi.

The Cubes work better with Slush's proxy due to Longpoll support.  I think Luke-Jr is adding longpoll on a future version of BFG.

It's called a capacitor.

maybe you dont need to put your btc address in the cube? perhaps x:x,x:x would work

I think bfgminer does not pass this info to the pool (i could be wrong about this)

so if you have 3 cubes connected to one single proxy they will appear as one worker to the pool

I actually run 3 instances of bfgminer proxy on my pi, each using about 10% cpu. still way less than slush's so I can use three command lines

for eligius you use an underscore character after your bitcoin address for a worker name ex: '_worker1'

so if you want to have separate stats and reporting on each cube use mutliple command proxy's on the same machine, just use a different port for each one and a different worker name in the command line

say for example you have a cube at 192.168.1.125 to keep it simple you can call him worker125 or cube125 or simply 125

command line

./bfgminer -o stratum+tcp://stratum.mining.eligius.st:3334 -O _125 --http-port 8125
./bfgminer -o stratum+tcp://stratum.mining.eligius.st:3334 -O _126 --http-port 8126
./bfgminer -o stratum+tcp://stratum.mining.eligius.st:3334 -O _127 --http-port 8127


the interesting thing with bfgminer is that you can use it to mine with other devices and act as proxy all with one instance
so you could be using it to run a butterfly labs miner, and a few usb sticks, and also have a cube connected to it's proxy. All three devices will appear in bfg miner and stats can be read there
but i think it all appears as one worker to the pool,

please if I am wrong about this some one let me know?

so why use the -o in bfgminer if the cube has already the user?

sorry alex, you asked me about the user field.

I guess you wanted to know about user / password?

:,:

at eligius your bitcoin payment address is all it really want to know but you should still enter a password for the cube so use

:,:

i just use a 'x' for my password, but dont tell anyone

you put the ip of your machine that is running the proxy

and in the field above 'pool ports' you use the port you specified in the bfgminer command line "--http-port 8332"

in that case use 8332 as the pool ports

In the cube settings, what i should put in the user field?

Hi Alex,

I am glad to help but better to do it here instead of PM, this way all can see.


here is the command I use to connect to eligius (a very good no fee pool, dont even need to register, just use your payment address as your username)

 here is the command I use on the raspi

./bfgminer -o stratum+tcp://stratum.mining.eligius.st:3334 -O --http-port 8332


you have to be sure to make sure you have all the dependancies installed when you build the bfgminer on the raspi (i used rasbian distribution of linux)

it was critical to have
libevent-dev
and
libmicrohttpd-dev

when you run ./configure so that it will be built with the proxy enabled.

if BFGminer was not built with proxy enable then it will give you an error when you try to use the '--http-port ' flag
error: ./bfgminer: --http-port: unrecognized option


go to this page
https://github.com/luke-jr/bfgminer

scroll down to the section on 'BUILDING BFGMINER'

should i switch my slush proxy on the raspi? (two cubes)

i found raspi could even handle two cubes running slushes proxy, it overloaded it. Going to BFGminers proxy solved it, can now run all the cubes on raspi

Woops, now I've just noticed something. One of my blades has an "X" and it appears stuck on long poll 'inactive'- any ideas?
 
Hash and efficiency look good, not entirely sure what this all means, pic below should explain my questions:

I've got my new cube running at 33gh/s but efficiency only says 85%. It's on a switch with 10 blades, all pointing at Bfgminer running in proxy mode. Any ideas if I can do anything to make this thing run around 95% like my other cube??

Edit: just added proxy to my Raspberry Pi and it's running a little bit better but not quite stabilized. Regardless, better, we'll see how it goes I guess. Maybe it was network traffic fighting with all the blades for the same proxy??

Edit2: well, pushing to my Rasberry Pi solved the issue, efficiency is around 94% and gh/s is climbing above 33... In the process one of my USB erupters got knocked out of play, but powering off the Rpi eventually fixed it so that all the connected devices work along with the proxy for the cube. Cool stuff, considering another Rpi for my cube arriving in a few days, will see how it goes.

I found in the 1st Cube this component with some black things... like burnt !

http://img15.hostingpics.net/thumbs/mini_35518920140106144650issue.jpg