An ASIC miner connected to a mining pool needs relatively little bandwidth and data. Bitmain's published ANTMINER guidance estimates approximately 500 MB of data use per miner per month and states that a 1 Mbps connection can support up to 150 miners. These are generic planning references, not a minimum internet speed requirement for each miner. The miner performs its proof-of-work calculations locally; its pool connection carries mining jobs and share submissions. Once sufficient bandwidth is available, connection stability and timely communication with the pool matter more than a higher advertised internet speed (Bitmain Support).
Bandwidth vs latency
Bandwidth (commonly measured in Mbps) describes how much data a connection can move per second. Latency describes how long a packet takes to reach the pool server and return. These are different properties, and an ASIC miner is far more sensitive to the second than the first.
In ordinary pool mining, the miner's network traffic consists of: establishing a Stratum connection, receiving new mining jobs, receiving an updated share-difficulty target when the pool uses variable difficulty, submitting shares that meet that target, and reconnecting if the configured connection drops. None of this requires transferring the miner's full computed hashes — only the shares it finds. Because of this, a higher-hashrate machine does not create proportionally higher network traffic; pools generally regulate share-submission frequency through variable difficulty rather than letting faster hardware flood the connection. Braiins Academy, documenting its own pool's implementation, targets roughly 12 share submissions per minute per worker — a pool-specific configuration example rather than a universal rate, but illustrative of why submission frequency, not hashrate, drives traffic volume (Braiins Academy).
Bitmain's published ANTMINER guidance offers two planning references: an estimated 500 MB of data use per miner per month, and a bandwidth-sizing rule of 1 Mbps for every 150 miners. These figures come from the same vendor document and are not independently measured results; they do not specify a particular model, firmware version, or pool. Averaged over a 30-day month, 500 MB works out to roughly 1.54 Kbps of continuous throughput, while the 1 Mbps-per-150-miners rule implies about 6.67 Kbps allocated per miner. These figures measure different things: the monthly estimate describes cumulative data transfer, while the bandwidth-sizing rule describes connection capacity. Bitmain does not explain the difference between the two values. Operators should treat both as planning estimates rather than fixed requirements (Bitmain Support).
Measure real traffic
Because manufacturer estimates are generic, the most reliable way to size a connection is to observe actual traffic from the equipment in use. Most consumer and small-business routers report per-device or per-port data transfer; managed switches used in larger deployments typically expose per-port throughput and error counters. Reviewing these figures over several days gives a realistic baseline, since mining traffic is bursty around job changes and share submissions rather than constant.
Scaling Bitmain's 500 MB per-miner-per-month estimate linearly gives a rough planning range: a single miner would use approximately 500 MB per month; ten miners approximately 5 GB; one hundred miners approximately 50 GB; three thousand miners approximately 1.5 TB. These are simple linear projections from a vendor estimate, not a measured deployment result, and they exclude any other traffic on the same connection — firmware downloads, remote monitoring dashboards, security cameras, or other devices sharing the network.
At facility scale, Bitmain's infrastructure guidance, last updated in July 2019, uses the formula bandwidth (Mbps) = number of machines ÷ 150. Its 3,000-machine example specifies at least 20 Mbps upload and 20 Mbps download on each enterprise broadband connection, within a design using at least two internet service providers. This is a vendor-published planning reference for large mining centers, not an independently measured result or a universal requirement for every mining operation. Operators should also budget for monitoring, remote administration, and other traffic sharing their connections (Bitmain Support).
Compare wired and backup links
Bitmain documentation states that ANTMINER units connect via Ethernet and do not support Wi-Fi. This is a statement about ANTMINER hardware specifically rather than a claim about every ASIC brand, but wired connections are generally preferred in mining deployments because they offer more consistent latency and fewer dropped packets than wireless links, particularly in facilities with many devices and potential interference.
Beyond the physical connection type, configuring an alternative connection port — where the miner's firmware supports multiple Stratum addresses — can help if the primary port cannot be reached. ViaBTC's current BTC mining documentation lists the following endpoints on the same domain and recommends configuring multiple ports:
stratum+tcp://btc.viabtc.io:3333
stratum+tcp://btc.viabtc.io:443
According to ViaBTC's guide, if the miner cannot connect using the first configured entry, it can switch to the next configured port and continue mining (ViaBTC Support). This does not increase a miner's hashrate or reduce its data usage; it is a connection-continuity measure, and actual failover behavior depends on how the specific miner's firmware handles multiple configured pool entries. Because these entries use the same domain and internet connection, switching ports does not provide protection against an ISP outage or a DNS failure affecting that domain, and it does not replace a backup internet connection.
Check data caps and outages
For operators on mobile, satellite, or other metered connections, the monthly data allowance matters more than peak speed. Bitmain's 500 MB per-miner-per-month estimate is a reasonable starting point for budgeting against a data cap, though actual usage can be higher if the deployment also includes remote monitoring software, firmware updates, or a locally run Bitcoin node.
Pool-connected ASIC mining does not require the miner to download the full Bitcoin blockchain. If you separately run a Bitcoin full node, budget for its synchronization and ongoing network traffic in addition to the miner's pool traffic (Bitcoin.org).
Outages are generally more disruptive to mining than a temporarily slower connection, since a disconnected miner stops submitting shares until it reconnects. When evaluating a connection for mining, it is reasonable to look at the provider's documented reliability, whether the service has a history of extended outages, and whether a backup internet source — such as a secondary ISP or cellular failover — is justified by the scale of the operation. This is a cost-and-risk tradeoff that depends on the size of the deployment rather than a fixed requirement.
Validate accepted shares
A rejected share is the umbrella category that a pool dashboard typically reports; stale, invalid, and duplicate shares are specific rejection reasons underneath it, not separate categories at the same level. A stale share is generally one submitted after the relevant work has become outdated — for example, after the network has moved on to a new block and the pool has distributed new work. Network latency and packet loss can contribute to stale or rejected shares by delaying either the delivery of new jobs to the miner or the submission of a found share back to the pool.
However, network conditions are not the only possible cause. Rejected shares can also result from miner-side issues such as firmware bugs, incorrect pool or worker configuration, or hardware faults, as well as pool-side validation rules. Before attributing a rejection pattern to the internet connection, it is worth reviewing the miner's own logs and the pool's rejection reason codes, where the dashboard provides them, rather than assuming a single cause.
It also helps to keep different measurements distinct when diagnosing an issue. A miner's locally reported hashrate is a device-side reading; the pool's displayed hashrate is a separate, pool-side estimate derived from submitted shares over a stated time window. Because share submission is probabilistic, short-term differences between these two readings are expected and do not necessarily indicate a hardware or network problem — comparing longer, equivalent time windows gives a more reliable picture than reacting to a single short-term dip.
FAQ
Does faster internet increase hashrate?
No. Hashrate is a function of the ASIC chips and their operating conditions; it is computed locally and is not increased by a faster internet connection. A stable connection helps the miner submit shares and receive new jobs promptly, but it does not change the device's computational output.
Can an ASIC mine on mobile or satellite internet?
It can work in principle, since the data volumes involved are generally modest, but mobile and satellite connections often carry higher latency, variable packet loss, and strict data caps. Reviewing the specific plan's data allowance against an estimate like Bitmain's 500 MB per miner per month, and testing the connection's stability over several days, is a reasonable way to evaluate suitability before committing.
How much data does a mining farm use?
Using Bitmain's published estimate of roughly 500 MB per miner per month as a linear planning figure, a 100-miner site would use on the order of 50 GB per month and a 3,000-miner site on the order of 1.5 TB per month, excluding monitoring systems, firmware updates, and any other infrastructure sharing the same connection.
Why does the pool show a lower hashrate than the miner interface?
The pool's displayed figure is a share-based estimate over a defined time window, while the miner's local display reflects the device's own measurement. Short-term differences are normal because share discovery is probabilistic; if the gap persists over a longer window, it is worth checking for connectivity issues or an elevated rejected-share rate rather than assuming a hardware fault from a single reading.