Bandwidth is almost never the limiting factor in an ASIC mining operation — latency and connection reliability are. A single Antminer or Whatsminer talking to a pool over Stratum moves only a few kilobits per second: it receives new work when a block is found (and on periodic clean-job pushes) and submits shares as it finds them. What actually breaks hashrate at scale is network quality — round-trip latency that turns valid shares into stale ones, flapping links that silently drop pool connections, and undersized switching or DHCP that can’t handle a full rack. This guide covers how mining traffic really behaves, how to diagnose load problems, and how to build a network that keeps every board submitting.
How Much Bandwidth a Miner Actually Needs
Stratum, the protocol every ASIC uses to talk to a pool, is JSON-RPC 2.0 over a single long-lived TCP connection (plain or TLS, commonly port 3333). The messages are tiny: a mining.notify job, a mining.set_difficulty update, and a stream of mining.submit shares. In practice each miner averages on the order of a few kilobits per second — a rounding error next to a household connection.
This is why the old “servers ÷ 150 = Mbps” rules of thumb from web-hosting are misleading here. Even a large fleet of several thousand ASICs rarely pushes more than single-digit megabits of sustained Stratum traffic. If you are sizing an uplink, the miners are not your problem — monitoring dashboards, firmware image pushes, and any co-located compute are. Provision for those, not for the hashboards.
The Real Bottleneck: Latency and Stale Shares
Because a new block invalidates all outstanding work, every miner must receive the fresh job and get its shares back to the pool before that work goes stale. High round-trip latency — a distant pool, a congested switch, a saturated home uplink, or Wi-Fi in the loop — means shares arrive after the pool has moved on. The pool rejects them with Job not found (stale job ID) or Low difficulty share, and that work is unpaid.
Stratum V2 exists largely to close this gap: its binary framing cuts wire traffic by roughly 70% and delivers jobs in single-digit milliseconds versus the hundreds of milliseconds typical of V1 JSON. Native SV2 support currently ships in BraiinsOS+ and in AxeOS v2.14.0+ (Bitaxe). On a V1 pool, the equivalent defenses are picking a geographically close pool, keeping the LAN wired, and watching your reject rate.
- Read the reject rate, not the bandwidth graph. A healthy fleet sits near 0–1% stale/rejected shares. A creeping reject rate is your early warning of a latency or link problem.
- Ping the pool from inside the network. Test round-trip time to the pool host from a machine on the same subnet as the miners. Consistent high or spiky latency points at the local path, not the pool.
- Kill Wi-Fi and powerline links. ASICs belong on wired Ethernet. Wireless bridges add jitter that directly converts to stale shares.
Connection Drops and Failover
A dropped Stratum session, not saturated bandwidth, is the more common outage. Switch reboots, DHCP lease expiry, a pool sending client.reconnect for maintenance, or a flapping SFP will all sever the connection. Note that a miner which loses its pool or network does not keep hammering at full power — modern firmware idles or throttles hashing when it can’t submit shares, so a rack that has gone quiet on the dashboard may simply be waiting to reconnect.
- Configure backup pools. Set at least two pool URLs (primary plus failover) in the miner so a single endpoint outage doesn’t stop hashing.
- Use static leases or a generous DHCP scope. A /24 (254 usable addresses) with short leases can starve at a few full racks. Reserve addresses by MAC or expand the scope before you scale.
- Check the switch, not the miner, first. Multiple boards dropping together almost always means an upstream switch, uplink, or DHCP fault — not simultaneous hardware failure.
Scaling the Network Infrastructure
Load problems in a hashcenter are switching and cabling problems. Each ASIC needs one 100 Mbps/1 GbE port; a 48-port switch handles a rack, but the uplink from that switch back to the router is what carries aggregate monitoring and management traffic. Size uplinks and count total ports before adding machines.
- Segment the fleet. Put miners on their own VLAN or subnet, isolated from office and camera traffic, so a broadcast storm elsewhere can’t disrupt Stratum sessions.
- Budget for monitoring overhead. Polling every miner’s API for hashrate, temps, and fan RPM every few seconds is far more traffic than the mining itself. Stagger polls and cache results.
- Plan firmware rollouts. Pushing an OTA image to a whole rack at once is the one time you will actually saturate a link. Batch updates rather than flashing everything simultaneously.
Diagnostic Checklist
- Open the miner’s status page and read accepted vs. rejected/stale share counts — this is the single best health signal.
- Confirm the miner shows a live pool connection and a real difficulty, not “dead” or a stalled job.
- Measure round-trip latency to the pool from the miner’s subnet.
- Verify the miner pulled a valid IP, gateway, and DNS from DHCP — a bad DNS entry silently blocks pool resolution.
- Check switch port link/error counters for CRC errors or flapping that signal bad cabling.
- If a whole group is down, work upstream (switch → uplink → router → ISP), not board by board.
Related
Pin down protocol behavior in the Stratum V1 glossary entry and the stale share definition, isolate a non-communicating board with the ASIC fault finder, and pull setup and network-config references from the miner manuals library.
