Topic: Solo mining new block detection lag (BFGMiner --expiry value) (Read 2613 times)
One thread on this is enough. Please lock this one and point to the other.
Hello all,
I started mining solo few days ago and I noticed a significant lag in new network block detection by both my Bitcoin Core (v0.9.0-beta 64-bit) and further by BFGMiner (3.10.0). When I see a new block on blockchain.info, from that point it takes about 120 seconds for it to appear in my Bitcoin-Qt's debug.log and then it takes another 120 seconds for my BFGMiner to report "New block detected on network". That's about 4 minutes of lost time, since I am pretty sure that my ASIC miners won't start mining the new block until both my Bitcoin Core and BFGMiner know about it.
I started playing with --expiry option in BFGMiner and found out that if I make it less than the default 120 seconds, then BFGMiner will recognize there's a new block on the network faster. For example:
./bfgminer --http-port 8330 -o http://127.0.0.1:8332 -u user -p password --coinbase-addr 1F2qbpkfApQm2gM63YvjTauyjaHxq2oekS --coinbase-sig "Cube102" --expiry 20
I would like to make the --expiry value even less, let's say 10 seconds, so I start working on a new block as soon as possible. 4 minutes is not acceptable since my miners on average lose 40% of chance to find a new block. That's 40% of lost electricity. Additionally I see quite a few "inputs already spent" and "already have block X" in my Bitcoind debug.log, which may be related to the fact that I'm still working on the block that has been already solved.
My question therefore is, can I safely use --expiry 10 (or maybe even 5) or will that cause BFGminer to consider some shares stale, while they are still valid. I've read somewhere that when mining solo, you don't submit any shares so that shouldn't have any negative impact, but I may be wrong. Can I use --expiry 10 with my BFGMiner and what else can be done to make both Bitcoind and BFGMiner recognize faster the fact that there's a new block on the network while mining solo? Thanks.
https://dl.dropboxusercontent.com/u/77333437/2014-03-30_13-07-58.png
I started mining solo few days ago and I noticed a significant lag in new network block detection by both my Bitcoin Core (v0.9.0-beta 64-bit) and further by BFGMiner (3.10.0). When I see a new block on blockchain.info, from that point it takes about 120 seconds for it to appear in my Bitcoin-Qt's debug.log and then it takes another 120 seconds for my BFGMiner to report "New block detected on network". That's about 4 minutes of lost time, since I am pretty sure that my ASIC miners won't start mining the new block until both my Bitcoin Core and BFGMiner know about it.
I started playing with --expiry option in BFGMiner and found out that if I make it less than the default 120 seconds, then BFGMiner will recognize there's a new block on the network faster. For example:
./bfgminer --http-port 8330 -o http://127.0.0.1:8332 -u user -p password --coinbase-addr 1F2qbpkfApQm2gM63YvjTauyjaHxq2oekS --coinbase-sig "Cube102" --expiry 20
I would like to make the --expiry value even less, let's say 10 seconds, so I start working on a new block as soon as possible. 4 minutes is not acceptable since my miners on average lose 40% of chance to find a new block. That's 40% of lost electricity. Additionally I see quite a few "inputs already spent" and "already have block X" in my Bitcoind debug.log, which may be related to the fact that I'm still working on the block that has been already solved.
My question therefore is, can I safely use --expiry 10 (or maybe even 5) or will that cause BFGminer to consider some shares stale, while they are still valid. I've read somewhere that when mining solo, you don't submit any shares so that shouldn't have any negative impact, but I may be wrong. Can I use --expiry 10 with my BFGMiner and what else can be done to make both Bitcoind and BFGMiner recognize faster the fact that there's a new block on the network while mining solo? Thanks.
https://dl.dropboxusercontent.com/u/77333437/2014-03-30_13-07-58.png
Jump to: