help setting up 2 mining rigs on local LAN.

megahz2megahz2 Member Posts: 36
edited February 2016 in Mining
How to setup 2 mine rigs on local lan to pool rigs?

I have been mining to dwarfpool with Stratum proxy,, l but want to try and mine locally.
This is what I have tried so far on my windows based, 2 mining rigs and 1 VM for –rpc

Geth --rpc --rpcaddr --rpcport 8545

Mining Rig1
= IP GPU=R9290x2
ethminer –G –F –opencl –cl-local-work 256 –cl-global-work 9216*256 –t 2

Mining Rig2 = IP 192.168.102 GPU=HD7990
ethminer –G –F –opencl –cl-local-work 256 –cl-global-work 9216*256 –t 2

Is the above right and/or What would be the command switches to make this work?
Note: I would like to send mined Ethereum to an entirely different wallet address of 0xBlahBlah.. and have been unsuccessful in finding command switches..

In advance, Thank You for your help!!
Post edited by megahz2 on


  • megahz2megahz2 Member Posts: 36
    I tried the above and after mining a wile I saw an error on the rpc vm that said:
    Dangling hash node ref 3cBlah-Long-Blah-Number: read C:\User\Me\AppData\Roaming\Ethereum\chaindata\082933.ldb: The handle is invalid.

    So I stopped and posted the original question "help setting up 2 mining rigs on local LAN"
  • dlehenkydlehenky Member Posts: 2,249 ✭✭✭✭
    @megahz2 The error you received has nothing to do with mining. You had an error processing the blockchain. There's a "recover" command for 'geth', which I've never used, but you may want to try it. Otherwise you should reload the blockchain from scratch. You can't mine until the blockchain is correct and fully in sync.

    -Best Care
  • megahz2megahz2 Member Posts: 36
    @dlehenky thank you for the quick response, I am looking into the command now.

    Any thoughts on command switch for forwarding mined ethereum to another account address 0xblahBlahh?
    If I can only use --etherbase "0" or "1" thats ok but where do I put --etherbase "1" in the mining rig or the rpc vm?? if its on the miner, I have different addresses on each miner.. so I would have to import the one account address on both miners right??

    Thanks again!!
  • dlehenkydlehenky Member Posts: 2,249 ✭✭✭✭
    I have no idea. I created a new etherbase account when I first installed 'geth' months ago. When I mine, that's where it all goes. I don't use a '--etherbase' option anywhere. Personally, I use to transfer the ether from my etherbase account in 'geth' to an exchange for conversion. HTH.
  • megahz2megahz2 Member Posts: 36
    Dangling hash node ref error must have been a fluke. all appears ok.
    I am back to trying to mine.. and my 2 rigs seem to be ok so far..

    Is it ok to have 2 rigs mining to 1 geth instance or do i need 2 instances?
    Geth --rpc --rpcaddr --rpcport 8545
    Geth --rpc --rpcaddr --rpcport "8545"
    Geth --rpc --rpcaddr --rpcport "8546"
  • dlehenkydlehenky Member Posts: 2,249 ✭✭✭✭
    @megahz2 Nope, one 'geth' for all. You wouldn't want to continuously download the blockchain for each rig. And the default port is 8545; you don't need to specify it on the command line.
  • megahz2megahz2 Member Posts: 36
    @dlehenky Thank You so much!! :)
  • megahz2megahz2 Member Posts: 36
    edited February 2016
    It seems that one DAG is created on each local rig located in C:\Users\MSFT-SucMe\AppData\Ethash diectory.

    Is a need or a way to verify the DAG integrity?
    or do I have to wait for a found block or uncle to see an error like, Dangling hash node ref# in geth --rpc
    Post edited by megahz2 on
  • dlehenkydlehenky Member Posts: 2,249 ✭✭✭✭
    @megahz2 No, there's no need (or way, that I know of) to check the DAG. If you think it's corrupt, stop the miners, delete the DAGs, and start the miners again. I wish I had time to put together a FAQ, because I end up repeating myself numerous times in different threads. There are always 2 DAGs that must be present. One is the current DAG that is being used to mine blocks. The other (larger) one is the DAG being pre-generated, as you go, in preparation for the next epoch (30,000 blocks), when the DAG is updated. The next DAG will *not* be pre-generated if all your ethminers are running with '--no-precompute'. That's generally not what you want to do, since you'll stop dead when the epoch occurs while you wait to generate the new DAG from scratch. When you start up, if you have current DAGs already, ethminer will bring the *next* DAG up to date. If your DAGs are current, ethminer will generate them. If you are also running 'geth', and using ethminer to mine, you do *not* want to run 'geth' with '--autodag', because it will conflict with 'ethminer' trying to update the DAG files. If you are running multiple ethminers on one rig, all but one *should* have the '--no-precompute' option, so only one ethminer is updating the DAG. HTH
  • megahz2megahz2 Member Posts: 36
    wow that's a lot to take in, I will need to think about your reply..
    I wish I new where that Dangling hash node ref# in geth --rpc came from.

    1. is there a DAG needed on the --rpc vm with no mining going on or just on the miners?
    2. can I just delete the DAG in the C:\Users\MSFT-sucky\AppData\Ethash folder and then restart miner on each rig?
    3. I only see the 1 DAG,, you mentioned 2 DAGs where is the other to delete or does it update the one DAG live/on the fly?

    yes, I wish you didn't have to repeat and I wish there was a way to consolidate structure and command switches. maybe keep a notepad to copy and paste
    U ROCK!!
    Thanks You!!!!!!!!!
  • dlehenkydlehenky Member Posts: 2,249 ✭✭✭✭
    @megahz2 Both DAGs live in the same folder. It sounds as though you aren't pre-computing the next DAG. Do you run one ethminer per rig or multiple? Are you using the '--no-precompute' option on ethminer? Somethings weird, because you should have 2 DAGs if you are pre-computing the DAG for the next epoch.

    Yes, you can stop ethminer, delete the DAGs, and start ethminer again to rebuild the DAG files from scratch.
  • megahz2megahz2 Member Posts: 36
    edited March 2016
    @dlehenky After deleting the DAG and restarting ethminer there are now 2 DAGs on each rig.
    No, I an not using --no-precompute.
    All appears fine now, I will run the rigs for a couple days to see if I get a block..

    Note: as the rigs finished generated the 1st DAG they started mining, as they are mining they are generating another DAG file, that must be the other larger DAG that's created and added to as time goes on for the next epoch?

    Thank U for your time!!!!!! :)
  • dlehenkydlehenky Member Posts: 2,249 ✭✭✭✭
    @megahz2 My pleasure! I'm happy to see you have 2 DAGs now.
  • megahz2megahz2 Member Posts: 36
    @dlehenky mining is going well!! :)
    Do you know how to mark this thread as answered or closed?
  • dlehenkydlehenky Member Posts: 2,249 ✭✭✭✭
    @megahz2 The forum doesn't do that well. If you start the discussion as a question, you can mark it as answered, but then anyone else that posts to it prompts you, forever, if they answered your question, even though you've already marked it as answered. Annoying. I've never looked into how to close one. Some of the old, original discussions are marked closed, though.
  • megahz2megahz2 Member Posts: 36
  • megahz2megahz2 Member Posts: 36
    sorry for stepping on that other forum thread.
    I did learn that I don't need the *256

    originally first posted above: Mining Rig1 = IP GPU=R9290x2
    ethminer –G –F –opencl –cl-local-work 256 –cl-global-work 9216*256 –t 2
    Erattic 43, 58, 66MH/s

    has now been changed to:
    ethminer –G --farm-recheck 200 –F –opencl –cl-local-work 128 –cl-global-work 4096 –t 2
    I now get a steady 52, 54MH/s

    Question thou, I added the --farm-recheck you mentioned,
    if I set --farm-recheck to 100 my MH/s flutters more erratically from 45, 48, 54, MH/s

    Does setting the farm refresh to low stop the GPU from finishing its hash cycle?
  • dlehenkydlehenky Member Posts: 2,249 ✭✭✭✭
    @megahz2 No worries, I didn't think you did anything wrong, I was just confused by the conversation getting mixed together (@ is your friend :) You don't need '--cl-local-work', just drop it and increase '--cl-global-work' to 8192; the two are exactly equivalent.

    Are you running eth-proxy on each rig, or one for all? I run one per rig, so the recheck is not happening over the network, it's internal to the system that's running both eth-proxy and ethminer (-F The recheck is how frequently ethminer polls eth-proxy, in this case, for new work. The more frequently you poll for work, the more overhead for both ethminer and eth-proxy. When you run them on the same machine, the overhead is lower than running it over your local network. It also depends on your CPU. I'm running a 2-core 2-thread 3.6 GHz i3, so I can do a lot more, without pain, than a 2.6 GHz Celeron .The recheck does not impact the GPU directly, however it does increase the load on the CPU with polling activity, which may delay the CPU somewhat in launching kernels especially on slow CPUs.
  • megahz2megahz2 Member Posts: 36
    I haven't mined a thing in 4 days, my Geth instance was stuck and couldn't shut it down 2 days ago I had to ctrl C panic to get out..
    And now I am at my 2 day mark, just waiting again..

    I am not woried about overhead, I have 32gb of ECC/chipkill ram and 2 8-core "E5-2650" CPUs,, system rocks..

    I do have a eth-proxy Question, will start a new thread becouse this one is cluttered with different topics..

  • megahz2megahz2 Member Posts: 36
    edited March 2016
    I updated Geth 1.3.5 & Ethereum 1.2.1 to homestead release.

    when running my 2 rigs to my one Geth --rpc instance,
    I noticed in geth --rpc that there was something strange @ importing block, 1101411 and block 1101412..there is block 1101411 imported twice.

    Note: because 1 rig is slower than the other I had:
    rig 1 running --farm-recheck 100
    rig 2 running --farm-recheck 150
    so I am pretty sure its because the farm-recheck time from the rigs was different.
    I did not remember seeing this before the update.. but after changing both rigs to --farm-recheck 100 there is only one block number now and all seems fine.

    my question is,
    1. there is a number next to the imported block number and they are different, what are those numbers?
    imported block 1101411 [dcd3b0db]
    imported block 1101411 [328cf972]

    Note2: I just saw duplicates @ block 1101536 [b4330d29] 1101536 [df343ab3], and I was not mining..
  • megahz2megahz2 Member Posts: 36
    Usually I find a block by day 2,
    I am on days 3
    maybe I'm having bad luck or something is up since I upgraded.
    I am worried about the --rpc log doesn't look right.
    any thoughts?

  • megahz2megahz2 Member Posts: 36
    since I updated Geth 1.3.5 & Ethereum 1.2.1 to homestead release. Now 4 days, No blocks, No Uncles, No luck..

    geth attach and listening with 25 peercount.
    miner.hashrate shows its 97MH/s hashing..

    note: YourIP:Port# shows

    geth 1.3.5 thinks I am on client id ++eth-v0.9.41-cd client ++eth-v0.9.41-cd "blank" ,, client version blank. OS blank

    geth ver 1.3.3 thinks I am on client id geth/v1.3.3/windows/go1.5.1 client Geth, client version v1.3.3

    not sure what is going on,
    I'm going to try reinstalling all 1.2.1 & 1.3.5
  • megahz2megahz2 Member Posts: 36
    hooray, I think i am up with geth v1.4.0-unstable.
    now i wait my 2 days and see if i get lucky.
  • dlehenkydlehenky Member Posts: 2,249 ✭✭✭✭
    @megahz2 It wont't be v1.4.0-unstable for long. It's being released with Homestead next Monday. I hope it all goes well for you this time!!
Sign In or Register to comment.