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.