Ninjastic
Search content
Sort by
Showing 4 of 4 results by abomb60
Post
Topic
Board Hardware
Re: [Guide] Dogie's Comprehensive ASICMiner Cube Setup
by
abomb60
on 31/12/2013, 05:16:45 UTC
Quote from: abomb60 on December 31, 2013, 04:13:36 AM
Ok so I found a workaround for my resetting problem.  On a hunch I changed the pool address in my cube to something that doesn't exist and noticed that it reset itself in about 2.5 minutes.  This told me that it wasn't a hardware issue since it hadn't been hashing.  After further experimentation I decided to try running BFGMiner on 2 different machines with the same --http-port parameter and set my pools to be the IP's of the 2 machines running BFGMiner on my LAN (192.168.210.29,192.168.210.46).  Both BFGMiner instances are connecting to the same pool (ghash.io) and using the same worker ID.  So far that seems to solve my problem and the cube uses the first BFGMiner pool for about 7 minutes then switches to the other.  Another 7 minutes later is switches back to the first pool and on and on.  This wasn't a problem for me since both of these computers are running all the time anyway.

Anyway hope this might help someone.  I saw some other posts that said moving the cube to another physical location (friends house) solved it and they thought it was network hardware related.  Before I ran the 2 BFGMiner instances I tried various switches and none of that fixed the problem.  I'm wondering did you use the same version of proxy or BFGMiner running on the same hardware that you used at home?

If this helps you and you would like to give me a donation use 181t3TwvFXN4CebByLxjt3dkvgZkEBL8PY

I just tried running 2 instances of BFGMiner on the same computer using different HTTP ports.  Command used to run them were:

bfgminer -o us1.ghash.io:3333 -u abomb60.worker1 -p xxxx --http-port 1234
bfgminer -o us1.ghash.io:3333 -u abomb60.worker1 -p xxxx --http-port 1235

This DIDN'T work for some reason.  The cube would connect to both pools if you set them to be primary but wouldn't fail to the 2nd. I'm thinking there is something odd going on in the cubes TCP stack causing this.  Time to break out Wireshark and take a look at the traffic.
Post
Topic
Board Hardware
Re: [Guide] Dogie's Comprehensive ASICMiner Cube Setup
by
abomb60
on 31/12/2013, 04:13:36 UTC
Ok so I found a workaround for my resetting problem.  On a hunch I changed the pool address in my cube to something that doesn't exist and noticed that it reset itself in about 2.5 minutes.  This told me that it wasn't a hardware issue since it hadn't been hashing.  After further experimentation I decided to try running BFGMiner on 2 different machines with the same --http-port parameter and set my pools to be the IP's of the 2 machines running BFGMiner on my LAN (192.168.210.29,192.168.210.46).  Both BFGMiner instances are connecting to the same pool (ghash.io) and using the same worker ID.  So far that seems to solve my problem and the cube uses the first BFGMiner pool for about 7 minutes then switches to the other.  Another 7 minutes later is switches back to the first pool and on and on.  This wasn't a problem for me since both of these computers are running all the time anyway.

Anyway hope this might help someone.  I saw some other posts that said moving the cube to another physical location (friends house) solved it and they thought it was network hardware related.  Before I ran the 2 BFGMiner instances I tried various switches and none of that fixed the problem.  I'm wondering did you use the same version of proxy or BFGMiner running on the same hardware that you used at home?

If this helps you and you would like to give me a donation use 181t3TwvFXN4CebByLxjt3dkvgZkEBL8PY
Post
Topic
Board Beginners & Help
Re: Debugging the Block Erupter Cube
by
abomb60
on 31/12/2013, 03:42:01 UTC
Quote from: abomb60 on December 29, 2013, 01:16:16 AM
Quote from: narlic on December 25, 2013, 07:12:29 PM
I switched to the slush proxy, and it stays up for between one and three days at a time now. But then it will still *click* and shut itself off, requiring a manual toggling of the power.

[edit] I'm using the slush proxy with the -rt option to relay the vardiff changes along to the cube directly. I'm not sure if that may be one of the reasons it stays up longer this way; back with the bfgminer proxy it would do the diff filtering on the miner software rather than the cube (I think... if I am wrong here please anyone feel free to correct me)

My cube came in today and it's acting a little weird.  It'll go for about 6 1/2 minutes then the MH/s will slowly start to drop.  BFGminer then declares it sick after 60 seconds of no response then it will come back.  Doesn't matter what the clock is set to and besides this it looks good with no X's for any of the ASIC's.  I tried replacing the cheap fuse it came with but that didn't seem to solve it either.  Power supply is a Cooler Master i600 which claims 48A on the +12v rail and from my research that should be fine.

Ok so I found a workaround for my resetting problem.  On a hunch I changed the pool address in my cube to something that doesn't exist and noticed that it reset itself in about 2.5 minutes.  This told me that it wasn't a hardware issue since it hadn't been hashing.  After further experimentation I decided to try running BFGMiner on 2 different machines with the same --http-port parameter and set my pools to be the IP's of the 2 machines running BFGMiner on my LAN (192.168.210.29,192.168.210.46).  Both BFGMiner instances are connecting to the same pool (ghash.io) and using the same worker ID.  So far that seems to solve my problem and the cube uses the first BFGMiner pool for about 7 minutes then switches to the other.  Another 7 minutes later is switches back to the first pool and on and on.  This wasn't a problem for me since both of these computers are running all the time anyway.

Anyway hope this might help someone.  I saw another post here in the hardware section but I can't post this there since i'm too new but if anyone would like to share this in that thread please do.

If this helps you and you would like to give me a donation use 181t3TwvFXN4CebByLxjt3dkvgZkEBL8PY

Thanks!

- Adam
Post
Topic
Board Beginners & Help
Re: Debugging the Block Erupter Cube
by
abomb60
on 29/12/2013, 01:16:16 UTC
Quote from: narlic on December 25, 2013, 07:12:29 PM
I switched to the slush proxy, and it stays up for between one and three days at a time now. But then it will still *click* and shut itself off, requiring a manual toggling of the power.

[edit] I'm using the slush proxy with the -rt option to relay the vardiff changes along to the cube directly. I'm not sure if that may be one of the reasons it stays up longer this way; back with the bfgminer proxy it would do the diff filtering on the miner software rather than the cube (I think... if I am wrong here please anyone feel free to correct me)

My cube came in today and it's acting a little weird.  It'll go for about 6 1/2 minutes then the MH/s will slowly start to drop.  BFGminer then declares it sick after 60 seconds of no response then it will come back.  Doesn't matter what the clock is set to and besides this it looks good with no X's for any of the ASIC's.  I tried replacing the cheap fuse it came with but that didn't seem to solve it either.  Power supply is a Cooler Master i600 which claims 48A on the +12v rail and from my research that should be fine.