<p>With pooled mining, at 900Mhash/s, you'll need a new work unit every 3 seconds or so. Each work unit requires about 256 bytes out and about 768 bytes back. So that's 700 bits per second out and about 2,000 bits per second back. Essentially, zero.</p>

<p>Solo mining is a bit harder to estimate. You will need to receive and relay all new blocks as they are discovered, you will need to receive all transactions that are relayed by nodes you connect to. You can heavily limit the number of other nodes you are willing to connect to, but this will impact your stale shares level and may reduce your transaction fee income.</p>

<p>I measured the bandwidth usage of the client with 60 connections (you can drop down to 8 if you want) and made sure my sample included discovering a block. The inbound average bandwidth was 12Kbps (1.50 KB/s) and the average outbound bandwidth was 9Kbps (1.04 KB/s). So that should give you an idea what solo mining would be like.</p>

<p>Notice that the bandwidth usage is basically insignificant in both cases.</p>

<p>For multiple rigs, there is no adjustment in the solo mining cases. All the rigs can be configured to query the single client. The client's bandwidth requirements will be the same.</p>

<p>However, there is a change in the pool mining case. When a new block is discovered, each miner will need a new work unit immediately since its existing unit is stale. This happens on average about every 10 minutes. Effectively, increase the bandwidth requirements by .5% for every additional mining rig. Note that if you run more than one instance of the mining program on a rig, count it as more than one rig. (This still assumes the rigs total 900Mhash/s.)</p>

CC BY-SA 3.0
2014-04-25T20:20:21.013Z
For multiple rigs mining to a pool, to decrease bandwidth usage one can run a stratum proxy locally that connects directly to the pool, and each miner then connects to the proxy. This way, each rig will only need to receive one work update per new block. One easy to use proxy for this is Slush's found here: http://mining.bitcoin.cz/mining-proxy-howto
vnhyp0
CC BY-SA 3.0
2011-09-02T20:56:41.560Z
If its useful I mined on remote tether with 7.2mb (optimal connection) I was on around 1500Mhash it worked perfect
MaxSan
CC BY-SA 3.0
2011-09-01T14:03:01.177Z
Great info, very specific, thank you. My interest is in knowing the number of rigs my current connection could support, and also the feasibility of using cell phone tethered internet. This answers that for me.
Mocky
CC BY-SA 3.0
2011-09-01T14:04:34.220Z
I updated my answer to be explicit about how multiple rigs affect things.
David Schwartz
CC BY-SA 3.0
2011-09-01T13:29:04.637Z
2011-09-01T14:06:16.510Z
2011-09-01T14:06:16.510Z
David Schwartz
<p>How much bandwidth consumption can I expect per 900 Mhash/s rig (for instance) for both pooled and solo scenarios? I'm looking for a ballpark number for the on going requirements, after the initial blockchain download.</p>

<mining-pools><solo-mining><bandwidth>
What are the bandwidth requirements of a mining rig?
Mocky
# What are the bandwidth requirements of a mining rig?

(Asked by: username_0 on 2011-09-01)

How much bandwidth consumption can I expect per 900 Mhash/s rig (for instance) for both pooled and solo scenarios? I'm looking for a ballpark number for the on going requirements, after the initial blockchain download.

**Tags:** mining-pools, solo-mining, bandwidth


---

## 1 answers

### Answer by username_1 on 2011-09-01. Score: 34 | Accepted answer

With pooled mining, at 900Mhash/s, you'll need a new work unit every 3 seconds or so. Each work unit requires about 256 bytes out and about 768 bytes back. So that's 700 bits per second out and about 2,000 bits per second back. Essentially, zero.

Solo mining is a bit harder to estimate. You will need to receive and relay all new blocks as they are discovered, you will need to receive all transactions that are relayed by nodes you connect to. You can heavily limit the number of other nodes you are willing to connect to, but this will impact your stale shares level and may reduce your transaction fee income.

I measured the bandwidth usage of the client with 60 connections (you can drop down to 8 if you want) and made sure my sample included discovering a block. The inbound average bandwidth was 12Kbps (1.50 KB/s) and the average outbound bandwidth was 9Kbps (1.04 KB/s). So that should give you an idea what solo mining would be like.

Notice that the bandwidth usage is basically insignificant in both cases.

For multiple rigs, there is no adjustment in the solo mining cases. All the rigs can be configured to query the single client. The client's bandwidth requirements will be the same.

However, there is a change in the pool mining case. When a new block is discovered, each miner will need a new work unit immediately since its existing unit is stale. This happens on average about every 10 minutes. Effectively, increase the bandwidth requirements by .5% for every additional mining rig. Note that if you run more than one instance of the mining program on a rig, count it as more than one rig. (This still assumes the rigs total 900Mhash/s.)

> **Comments:**
> **username_0**: Great info, very specific, thank you. My interest is in knowing the number of rigs my current connection could support, and also the feasibility of using cell phone tethered internet. This answers that for me.  
> **username_1**: I updated my answer to be explicit about how multiple rigs affect things.  
> **username_3**: If its useful I mined on remote tether with 7.2mb (optimal connection) I was on around 1500Mhash it worked perfect  
> **username_2**: For multiple rigs mining to a pool, to decrease bandwidth usage one can run a stratum proxy locally that connects directly to the pool, and each miner then connects to the proxy. This way, each rig will only need to receive one work update per new block. One easy to use proxy for this is Slush's found here: http://mining.bitcoin.cz/mining-proxy-howto  

---

