Internet for Bitcoin Mining: Latency, Stale Shares, and Why Bandwidth Doesn't Matter
Besides electricity and hardware, internet quality is one of the key factors in Bitcoin mining. Mining depends on continuous communication between your hardware and the pool, and it is the stability of this communication, not the connection speed, that determines how much of your work is counted.
Mining generates very little traffic, so bandwidth is rarely a bottleneck. What matters much more is:
- latency: how quickly data travels between the miner and the pool;
- jitter: how stable that delay is;
- packet loss: how much data fails to arrive.
This article explains what network requirements matter for efficient mining and which mistakes are most common.
Key takeaways
- Latency is how quickly mining hardware communicates with the pool server: the lower it is, the faster shares are submitted and new work is received.
- When shares arrive late, they become stale and are not paid.
- A latency below 50 ms is ideal, up to 100 ms is acceptable, and above 100 ms the risk of stale shares grows noticeably.
- Jitter and packet loss matter as much as latency: even 1% packet loss noticeably reduces your effective hashrate.
- A standard ICMP ping shows only basic reachability, while Stratum-level latency reflects real mining communication.
- Wired Ethernet, the nearest regional pool server, and a backup connection solve most network problems.
How pool latency affects mining
Most Bitcoin mining today goes through pools. In pool mining, devices constantly exchange small data packets with the pool: they submit shares and receive new work. That is why network responsiveness directly affects efficiency. In solo mining, communication is less frequent, so the network plays a smaller role.
Each time an ASIC finds a potential solution, it must be sent to the pool as quickly as possible. The lower the latency, the more likely the share will be accepted and credited.
Latency depends on:
- the physical distance between the miner and the pool server;
- the quality of the internet connection;
- the load and architecture of the pool's servers;
- general network congestion;
- routing between internet providers.
Why stale shares reduce profitability
A stale share is a correct solution that arrives after the pool has already moved on to a new block or new job. The computation is correct, but the share is rejected because of timing. The consequences:
- no payout: pools reward valid work on the current job, so stale shares are not paid under common payout models, including FPPS and PPLNS;
- wasted electricity: an ASIC consumes the same power regardless of whether its shares are accepted;
- lower effective hashrate: the higher the stale share rate, the less of your device's hashrate is reflected in the pool dashboard and in your earnings.
For example, if a 200 TH/s device has a 2% stale share rate, about 4 TH/s of its work is simply lost, while electricity costs remain the same.
The bandwidth myth: why you don't need gigabit internet
One of the most common misconceptions is that mining requires a fast connection. In reality, mining traffic is minimal and consists of small, frequent messages: receiving jobs and submitting shares. A top-tier modern ASIC generates about the same amount of traffic as an older model.
The traffic of a single device in normal operation is measured in kilobits per second, so even a farm with hundreds of machines does not need a high-speed connection. It is still worth leaving some headroom for remote management, monitoring, and firmware updates, which generate more traffic than mining itself.
Latency and connection stability affect results much more than bandwidth: a fast but unstable connection will cause more stale shares than a slow but stable one.
Key network metrics: ping, jitter, and packet loss
Ping: measuring latency
Ping measures round-trip time: how long it takes data to travel from the ASIC to the pool server and back. Latency is the delay itself, and ping is the tool used to measure it, in milliseconds.
General guidelines:
- below 50 ms: ideal;
- 50–100 ms: acceptable;
- above 100 ms: a noticeably higher risk of stale shares.
Ping can be checked from a computer on the same network by running the ping command with the pool server address in the terminal or command prompt.
Jitter: connection stability
Jitter is the variation in response time between consecutive measurements. If the connection jumps from 30 ms to 200 ms and back, jitter is high. This makes communication unpredictable: one job arrives instantly, the next one with a delay.
Packet loss: delivery reliability
Data travels over the internet in small packets. If a packet with a share is lost, the pool never receives the work. Even if the data is resent, by then the pool may already have moved to a new job, and the share will be rejected as stale.
Even 1% packet loss can noticeably reduce effective hashrate. Packet loss is measured with network tools that send a series of test packets and count how many return.
Benchmarks for mining connectivity
| Metric | What it means | Impact on ASIC mining | Target |
|---|---|---|---|
| Ping | Round-trip time between the ASIC and the pool server | Delays new jobs, so the hardware works on outdated data | Below 50 ms (acceptable up to 100 ms) |
| Jitter | Variation in response time | Makes share submission timing unstable | Below 5 ms |
| Packet loss | Share of packets that do not reach their destination | Shares do not reach the pool, and work is lost | 0% |
How to test pool latency correctly
Mining traffic differs from regular web traffic: it is continuous machine-to-machine communication over its own protocol. That is why a regular ping gives an incomplete picture.
ICMP ping vs. Stratum-level latency
A regular ping uses the ICMP protocol and only confirms that the server is reachable. The pool server may respond to it instantly while still delaying job delivery or share acceptance at the application level.
Most pools use the Stratum protocol, which runs over TCP and keeps a persistent two-way connection between the ASIC and the pool. Stratum-level latency measures the real round-trip time of a mining workload, including the time the pool's software needs to receive, process, and validate a share.
| Parameter | ICMP ping | Stratum-level latency |
|---|---|---|
| What it measures | Basic network delay | Real delay of mining communication |
| Protocol | ICMP | Stratum over TCP |
| Includes pool responsiveness | No | Yes |
| Main use | Connectivity check | Mining latency testing |
Stratum-level latency can be measured with specialized tools or directly on the hardware: both stock and custom ASIC firmware show protocol-level metrics in the device dashboard. Also, check the share of rejected and stale shares in the pool dashboard: it is the most direct indicator of how well your connection performs in practice.
Wired Ethernet vs. Wi-Fi
- Ethernet connects the device with a cable and gives a stable, predictable connection.
- Wi-Fi is easier to set up but more sensitive to walls, interference, and distance from the router.
Where stability matters more than convenience, Ethernet is the clear choice. Wi-Fi is more prone to fluctuations, which lead to delayed or lost shares.
Regional pool servers: why geography matters
Pools operate servers in different regions so that devices can connect to the nearest one. A shorter distance reduces latency and speeds up job delivery and share submission.
Connecting to a distant server makes the route longer and more complex, which increases latency and reduces stability. If you mine in a pool, such as EMCD Mining Pool, choose the regional server closest to your site from the connection settings, and compare latency to several servers before deploying the whole fleet.
It is also worth setting backup pool addresses in the device settings: if the main server becomes unavailable, the ASIC will automatically switch to the backup.
Failover and redundancy: Dual-WAN and LTE backup
To reduce the risk of downtime, mining operations often use more than one internet connection:
- a Dual-WAN setup connects the network to two independent providers at once. If the main connection fails, traffic switches to the backup automatically;
- LTE mobile internet is a practical backup where a second wired provider is unavailable. Latency on mobile connections is higher, but staying connected to the pool during an outage is better than a complete shutdown.
For operations where uptime directly affects revenue, a main wired connection plus an LTE backup is a reliable basis.
Monitoring network problems
Network problems are often invisible until payouts drop. That is why it is important to see them as they happen:
- watch the rejected and stale share rate in the pool dashboard;
- compare the hashrate on the device with the hashrate the pool sees;
- set alerts for devices going offline and sudden drops in hashrate.
For larger fleets, monitoring tools help here. EMCD Monitoring, for example, brings the whole fleet into one interface, alerts you when a machine goes offline or slows down, and helps determine the cause of a drop: the device, the pool, or the connection. It works with any pool and firmware.
How to reduce mining latency
Most latency problems come from an unstable or poorly configured network: weak Wi-Fi, an overloaded router, a distant pool server, or an unreliable provider. A network prepared in advance prevents these problems:
- Connect devices with Ethernet cables.
- Use a reliable router and switches that can handle the number of devices.
- Choose the nearest regional pool server and set backup addresses.
- Test latency, jitter, and packet loss before deploying the whole fleet.
- Set up a backup internet connection.
- Monitor the stale share rate and set alerts.
FAQ
What latency is considered good for Bitcoin mining?
Below 50 ms is ideal, and up to 100 ms is acceptable. Above 100 ms, the risk of shares arriving after the pool has moved to a new job grows noticeably.
Why does latency matter more than bandwidth?
Mining depends on how quickly data travels between the ASIC and the pool, not on how much data can be transferred at once. Mining traffic is minimal, so even a slow but stable connection works better than a fast but unstable one.
How much bandwidth do I need for mining?
Very little: one device in normal operation uses kilobits per second. Leave some headroom for remote management and firmware updates, but you do not need a high-speed plan.
What is Stratum-level latency?
The round-trip time between the hardware and the pool measured over the Stratum protocol, including the pool's processing time. Unlike an ICMP ping, it reflects real mining communication.
Why do slow connections increase stale shares?
Delays in submission increase the chance that a correct result reaches the pool after it has already moved to a new job, and such a share is rejected as stale.
Can I mine over Wi-Fi?
Technically yes, but Wi-Fi is more prone to fluctuations and interference. For stable mining, a wired Ethernet connection is recommended.
How do I know if my network is causing losses?
Check the stale and rejected share rate in the pool dashboard and compare the device hashrate with the hashrate the pool sees. A large difference usually points to network problems.
without growing costs
cryptocurrencies
