Mining on a Home DSL connection: latency for 1MB and 8MB blocks

I like data.  So when Patrick Strateman handed me a hacky patch for a new testnet with a 100MB block limit, I went to get some.  I added 7 digital ocean nodes, another hacky patch to prevent sendrawtransaction from broadcasting, and a quick utility to create massive chains of transactions/

My home DSL connection is 11Mbit down, and 1Mbit up; that’s the fastest I can get here.  I was CPU mining on my laptop for this test, while running tcpdump to capture network traffic for analysis.  I didn’t measure the time taken to process the blocks on the receiving nodes, just the first propagation step.

1 Megabyte Block

Naively, it should take about 10 seconds to send a 1MB block up my DSL line from first packet to last.  Here’s what actually happens, in seconds for each node:

  1. 66.8
  2. 70.4
  3. 71.8
  4. 71.9
  5. 73.8
  6. 75.1
  7. 75.9
  8. 76.4

The packet dump shows they’re all pretty much sprayed out simultaneously (bitcoind may do the writes in order, but the network stack interleaves them pretty well).  That’s why it’s 67 seconds at best before the first node receives my block (a bit longer, since that’s when the packet left my laptop).

8 Megabyte Block

I increased my block size, and one node dropped out, so this isn’t quite the same, but the times to send to each node are about 8 times worse, as expected:

  1. 501.7
  2. 524.1
  3. 536.9
  4. 537.6
  5. 538.6
  6. 544.4
  7. 546.7

Conclusion

Using the rough formula of 1-exp(-t/600), I would expect orphan rates of 10.5% generating 1MB blocks, and 56.6% with 8MB blocks; that’s a huge cut in expected profits.

Workarounds

  • Get a faster DSL connection.  Though even an uplink 10 times faster would mean 1.1% orphan rate with 1MB blocks, or 8% with 8MB blocks.
  • Only connect to a single well-connected peer (-maxconnections=1), and hope they propagate your block.
  • Refuse to mine any transactions, and just collect the block reward.  Doesn’t help the bitcoin network at all though.
  • Join a large pool.  This is what happens in practice, but raises a significant centralization problem.

Fixes

  • We need bitcoind to be smarter about ratelimiting in these situations, and stream serially.  Done correctly (which is hard), it could also help bufferbloat which makes running a full node at home so painful when it propagates blocks.
  • Some kind of block compression, along the lines of Gavin’s IBLT idea. I’ve done some preliminary work on this, and it’s promising, but far from trivial.

 

4 thoughts on “Mining on a Home DSL connection: latency for 1MB and 8MB blocks”

  1. > Some kind of block compression, along the lines of Gavin’s IBLT idea

    Keep in mind that’s both already implemented by Matt Corallo’s block relayer as well as p2pool, and unless all miners cooperate to make it work by adopting the same mempool policy it’s quickly degraded.

    If anything, the 10% orphan rate you’re seeing – which could easily be 2x your expected profit margin – indicates that even miners with relatively fast network connections are at a major disadvantage. Obviously this needs to get fixed thoroughly and the situation re-evaluated.

    1. Agreed. Downside of Matt’s relay is that it doesn’t help with *upload*. He suggested running a private relay to a better connected node, but that requires a second node and special setup, too.

      I am working on some marginal improvements for the IBLT proposal wrt. policy coherence, but we’ll see…

    1. Indeed, running a full node at home is quite painful due to buffer bloat, and Greg Maxwell (at least) reported that fq_codel helped immensely. Now to get it deployed on all home routers!

      But this test doesn’t improve with less buffering; it’s all throughput…

Comments are closed.