Does an Unstable Mine Network Increase Mining Costs? How Latency, Disconnections, and Reject Rates Affect Returns

For Bitcoin mining farms, the network is usually not the most expensive infrastructure. Compared with miner procurement, electricity, transformers, power distribution systems, and cooling equipment, broadband fees may account for a very small share of total operating expenditure. This also leads many mining farms to understand the network as merely a matter of whether miners can connect to the pool, and daily operations focus more on whether miners are powered on, whether fans are working normally, and whether hashboards have dropped, while ignoring the continuous erosion of actual returns caused by latency, network jitter, packet loss, frequent reconnections, and reject rates.

In fact, an unstable mine network does not necessarily directly increase the nameplate power consumption of miners, but it reduces the effective hashrate and effective mining time corresponding to the same electricity bill. Miners may still be running, fans may still be spinning, and the local dashboard may show near-normal instantaneous hashrate, but if the computation results are not submitted to the pool in a timely and correct manner, this portion of electricity consumption cannot form settleable revenue. The result is that mining farm revenue declines, while electricity fees, site fees, labor costs, maintenance costs, and equipment depreciation do not decline proportionally, ultimately manifesting as a rising cost per Bitcoin and a narrowing profit margin.

Therefore, to determine whether network problems increase mining costs, one cannot only look at whether the internet bill has gone up, but must look at how much pool-accepted effective work the mining farm actually obtains for each kilowatt-hour of electricity consumed. For mining farms in a lower profit margin range, even a long-term effective revenue loss of only 1% may have an impact on net profit far greater than 1%.

Why an Unstable Mine Network Increases Mining Costs

Bitcoin miners do not complete mining independently on-site and periodically upload their results. Miners need to continuously communicate with the pool, receive new mining tasks, and submit proofs of work that meet the pool's difficulty requirements to the pool. The Stratum V2 protocol specification summarizes this process as the pool or upstream server distributing work to miners, and miners submitting proof-of-work results back to the server. Each task contains the information a miner needs to perform its hash search, while the upstream server must also allocate sufficient and non-overlapping search space to different miners in a timely manner.

From a cost perspective, what a miner consumes is electricity, but what the pool settles is not every hash computation shown on the miner's dashboard, but rather the effective contributions confirmed and accepted by the pool. If a miner does not receive a new task because of a connection interruption and continues computing on the old task; or if a miner has already found a qualifying Share but submits it after the task has expired due to communication latency, then the electricity the miner has already consumed will not be refunded, yet the corresponding work may not receive a reward.

This means what network anomalies increase is not hourly electricity consumption, but the electricity cost that each unit of effective revenue must bear. For example, a miner running normally for one day consumes a fixed amount of electricity; when the network is normal it can obtain 100 units of effective revenue; if network problems cause a 2% loss of effective work, the same electricity fee can only obtain 98 units of effective revenue. Even if the electricity price has not changed, this miner's electricity cost per unit of revenue has already risen.

For the entire mining farm, the energy cost per Bitcoin can be understood in simplified terms as: energy cost per Bitcoin = total electricity fees during the statistical period ÷ actual number of Bitcoins produced during the statistical period. As long as network failures cause actual output to decline while total electricity fees do not decrease in the same proportion, the energy cost per Bitcoin will increase.

How Miners Submit Effective Work to the Pool via the Network

The pool distributes mining tasks to miners, and miners perform high-speed hash computation around the block header information specified by the task. When a miner finds a result that meets the pool's Share Difficulty, it submits the Share to the pool. The pool estimates the hashrate contributed by miners through these Shares and calculates returns according to the corresponding payment model.

f2pool's official documentation divides Shares into two categories: accepted and rejected. An accepted Share represents effective work recognized by the pool, and the pool calculates rewards accordingly; a rejected Share does not contribute effective work toward block discovery, so it usually does not receive a pool reward. f2pool also points out that farm-side latency is one of the common causes of rejected shares, because the miner may still be working on a task that has already been completed or expired.

In the actual link, a Share from generation to acceptance usually passes through the miner's NIC, the access switch, the aggregation switch, the farm router or firewall, the carrier line, internet routing, the pool's regional node, and the pool's backend server. If the mining farm has deployed a local Proxy, the miner must first connect to the Proxy, and the Proxy then aggregates communication upstream to the pool.

Congestion, port errors, insufficient sessions, excessive CPU load, or routing anomalies at any link may affect task distribution and Share submission. A miner dashboard showing "online" only indicates that a connection still exists at a certain point in time; it does not mean that every task was received in time and every effective Share was correctly submitted over the past hour.

What Is the Difference Between Bandwidth, Latency, Network Jitter, Packet Loss, and Disconnection

Mine network problems are often collectively called "bad network," but different problems affect mining in different ways. Bandwidth represents the amount of data the network can carry per unit of time. The volume of Stratum data transmitted between ASIC miners and the pool is usually far lower than that of video, cloud storage, or large-scale file transfers, so a mining farm does not necessarily need very high per-machine bandwidth. The real question is whether, once a mining farm has thousands of miners, multiple management systems, and monitoring services, the egress bandwidth, router session capacity, and proxy server throughput can stably carry all connections. Sufficient bandwidth does not mean latency must be low, and insufficient bandwidth does not necessarily immediately cause a complete disconnection.

Latency is the time it takes for data to travel from one end to the other. Mine operations commonly use Ping round-trip time as a preliminary reference, but Ping can only reflect the round-trip time of a specific test target at the moment of testing, and is not entirely equal to the real processing latency of Stratum task distribution and Share submission. Routing distance, cross-border lines, carrier congestion, pool server load, and intermediate proxies may all increase actual communication latency.

Network jitter is the degree of instability of latency. For example, an average latency of 80 milliseconds does not look outrageous, but if it is sometimes 30 milliseconds and sometimes suddenly rises to 500 milliseconds or even several seconds, the timing of the miner's result submission becomes difficult to predict. Compared with stable but slightly higher latency, severe jitter more easily causes intermittent rejections, connection timeouts, and frequent fluctuations in the pool-side hashrate curve.

Packet loss is when some network data does not successfully reach its target. A small amount of packet loss may trigger retransmission, manifesting as higher latency; continuous packet loss may cause connection resets, authentication failures, task reception anomalies, or lost submission results. The source of packet loss may be network cable quality, switch port errors, optical module failures, wireless link interference, carrier line congestion, or insufficient equipment performance.

Disconnection means the connection between the miner and the pool is interrupted for a period of time. A short disconnection may last only a few seconds or tens of seconds, and the miner quickly reconnects automatically, so operations staff will still see the device online when checking the dashboard, but a large number of short disconnections accumulate into considerable ineffective time. Long-term disconnections are easier to detect, because the pool will directly mark the Worker as offline or inactive.

Pool failures occur at the pool's regional nodes, domain name resolution, port services, or backend systems, and are not necessarily problems with the mine network itself. When determining the boundary of responsibility, one needs to compare connection results from different pool addresses, different ports, different carrier lines, and multiple geographic locations.

What Are Accepted, Rejected, Stale, Duplicate, and Invalid Shares

An Accepted Share is an effective submission confirmed by the pool as meeting the current task requirements and the pool's difficulty requirements. It is an important basis for the pool to estimate the miner's contribution and calculate returns.

A Rejected Share is a submission not accepted by the pool. But "rejected" is only a result and does not mean there is only one cause. Network latency, task expiration, duplicate submission, insufficient Share difficulty, parameter errors, firmware anomalies, unstable overclocking, and hardware errors may all produce rejections.

A Stale Share is usually work submitted by a miner based on a task that has already expired. When a new block appears on the Bitcoin network, the pool switches to a new work task. If the miner receives the update late, or the old task result is submitted too late, a Stale Share may form. Stratum V2 and the Hashlabs test case also list latency and inefficient communication as causes of stale shares, and describe this portion of work as wasted hashrate that cannot be paid.

A Duplicate Share is the same result submitted repeatedly. It may be caused by miner software, firmware, proxy forwarding, connection retries, or task management errors. A duplicate share does not represent additional work contribution.

An Invalid Share is a submission that does not meet protocol, task, or difficulty requirements. Its causes may include hardware computation errors, firmware problems, excessive overclocking, and time or parameter anomalies, and may also come from incompatibility between pool and miner configurations.

It is especially necessary to distinguish stale shares from stale blocks. Stale shares occur at the level of the miner submitting Shares to the pool, the number is usually very large, and a single Share does not mean the miner has discovered a Bitcoin block. A stale block is when a miner or pool has already successfully discovered a block that meets the Bitcoin network difficulty, but because of the simultaneous existence of a competing block or slow propagation, the block ultimately does not enter the main chain accepted by the network. Both are related to timeliness, but their economic impact and the level at which they occur are completely different.

Why the Pool-Side Hashrate Is Still Low When Local Hashrate Is Normal

Local miner hashrate is usually estimated from the device's hash computation status within a certain time window, representing how fast the chips are computing. Pool-side hashrate is inferred from the effective Shares actually received by the pool within a certain statistical window to derive the miner's contributed hashrate. The two have different data sources and statistical methods, so they cannot be completely consistent in the short term.

Local hashrate being normal but pool hashrate being low may have five categories of causes:

1. Different statistical windows. The miner may show instantaneous hashrate or a short-term average, while the pool shows a 10-minute, 1-hour, or 24-hour average;
2. Shares are inherently random; even if the miner's status is stable, the short-term submission count will fluctuate;
3. Some Shares are rejected or expired; the local computation has already occurred but has not entered the pool's effective statistics;
4. The miner reconnects frequently; after the connection recovers the device still shows running, but there is time in between with no effective submission;
5. Miner configuration, account, Worker name, pool address, or Proxy mapping anomalies cause some hashrate to be counted into other accounts or not correctly identified.

Therefore, troubleshooting low pool hashrate cannot rely only on comparing two hashrate numbers. A more reliable method is to simultaneously view the local hashrate trend, the number of accepted shares, the classification of rejected shares, online time, reconnection count, and the pool-side long-period average hashrate.

Device power-on rate and effective online rate should also be separated. Device power-on rate only indicates that the miner is powered or accessible; effective online rate should reflect the proportion of time the miner is actually connected to the pool and continuously submitting effective Shares. A miner can have nearly 100% power-on time yet have a low effective online rate because of network reconnections, task anomalies, or a high reject rate.

Why Low-Profit-Margin Mining Farms Are More Sensitive to Network Losses

Assume a mining farm has a theoretical daily mining revenue of 10,000 USD and a daily electricity fee of 8,000 USD. The following is only a scenario model used to explain profit sensitivity and does not represent the operating data of any real mining farm.

Network Loss Rate	Actual Revenue	Daily Electricity Fee	Daily Gross Profit	Decline vs. Normal Gross Profit
0%	10,000 USD	8,000 USD	2,000 USD	0%
1%	9,900 USD	8,000 USD	1,900 USD	5%
3%	9,700 USD	8,000 USD	1,700 USD	15%
5%	9,500 USD	8,000 USD	1,500 USD	25%

This case illustrates that the network loss rate and the profit decline ratio are not the same thing. When revenue drops by 5%, the mining farm's electricity fee does not drop accordingly; gross profit drops from 2,000 USD to 1,500 USD, a decrease of 25%.

If the mining farm also has to bear maintenance labor, site rental, insurance, pool fees, financing costs, and miner depreciation, the actual net profit margin may be even lower than the gross profit margin above. The thinner the profit margin, the more obvious the amplifying effect of network losses on net profit. For old miners near the break-even line or mining farms with high electricity prices, a reject rate that originally seemed not high may even determine whether a batch of miners continues to operate or falls into a loss.

How High Is a High Reject Rate, and How to Judge It

ViaBTC lists its platform's typical reject rate reference range as within 3%, and reminds users to check the network connection, miner temperature, and firmware problems when the reject rate fluctuates noticeably. But this figure is a troubleshooting reference provided by a specific platform and should not be interpreted as a unified passing line for the entire Bitcoin mining industry.

A more reasonable method to judge whether a reject rate is abnormal is to establish the mining farm's own long-term baseline. Suppose the reject rate of most racks in the same mining farm over the past 30 days has consistently remained at a low level, and one day a certain rack suddenly rises significantly; then even if it has not yet reached a certain general threshold, it is worth troubleshooting immediately. Conversely, if different pools count Stale, Rejected, and Invalid differently, directly comparing the total reject rates on the two platforms' dashboards may also lead to wrong conclusions.

A mining farm should pay attention to at least four categories of changes: first, whether the whole-farm reject rate rises in sync; second, whether a certain rack, switch, or miner batch is significantly higher than other areas; third, whether the reject rate rises simultaneously with network latency, packet loss, or reconnection count; fourth, whether a high reject rate appears simultaneously with high temperature, overclocking, firmware upgrades, or power anomalies.

For mining farms with lower profit margins, a long-term 1% effective revenue loss should not be easily ignored. The troubleshooting focus is not to argue whether 1%, 2%, or 3% counts as serious, but to confirm whether this loss can be avoided and whether the cost of improvement is lower than the ongoing loss.

Common Causes of Mine Network Anomalies and Troubleshooting Methods

Problem Type	Common Symptoms	Impact on Shares	Impact on Revenue	Troubleshooting Method	Solution
High latency	Ping and task response are persistently slow, pool hashrate lower than expected	Shares submitted late, Stale may increase	Effective hashrate and settleable revenue decline	Continuously measure latency to pool domains and nodes, check the routing path	Use closer pool nodes, optimize carrier and routing
Network jitter	Average latency normal, but occasional high-latency spikes	Intermittent Stale, timeouts, and reconnections	Revenue fluctuates, problem hard to find with a single test	Record latency distribution and high-end latency over a long period	Optimize link quality, set up continuous monitoring
Packet loss	Connection stutters, frequent retransmission, occasional authentication failure	Shares lost or submission timeout	Effective online rate and acceptance rate decline	Check port errors, link packet loss, and device logs	Replace network cables, optical modules, ports, or carrier lines
Short disconnection	Worker repeatedly goes online and offline, local miner still runs	No effective submission for a short time, may submit old task after connection recovers	After accumulating multiple times, forms hidden revenue loss	Check reconnection count and minute-level online status	Repair the link, optimize backup addresses and reconnection strategy
Long-term offline	Pool marks the Worker as offline	Stops submitting effective Shares	Revenue drops noticeably in proportion to offline time	Compare miner reachability, power, and pool connection	Restore the line, rule out power and hardware failures
DNS failure	Domain cannot be resolved, but the IP may be reachable	Cannot connect to the pool address	A batch of miners may go offline simultaneously	Test DNS resolution and backup DNS	Configure reliable DNS and local cache, keep a backup plan
Upstream carrier failure	Whole-farm external network abnormal or routing detour	A large number of miners reconnect or go offline simultaneously	Forms a farm-level revenue interruption	Test with dual lines separately	Deploy dual carriers and automatic failover
Farm Proxy failure	All miners behind the Proxy are abnormal, other areas normal	Shares cannot be uploaded, or many duplicates and timeouts	Single point of failure amplified into batch loss	Check Proxy load, sessions, logs, and upstream connection	Proxy redundancy, capacity planning, and health checks
Pool node failure	A single pool address abnormal, other nodes normal	Submission failures, connection timeout	Revenue declines during the corresponding pool connection	Switch regional node or port, or test other pools	Configure effective backup pools and test switching
Miner or firmware problem	Only some models or firmware versions have a high reject rate	Invalid, Duplicate, or abnormal Shares increase	Single-machine or batch revenue declines	Compare models, firmware, frequency, and hardware errors	Restore stable firmware, lower the frequency, repair hardware

A high reject rate does not necessarily mean the network has a problem. It may also be high temperature and firmware problems; this is also a very common misjudgment in mine operations. If the anomaly only appears in a certain miner model, a certain firmware version, or a batch of overclocked devices, while other miners on the same network are normal, then one should prioritize checking the miner and firmware rather than immediately replacing the internet line.

Mine Network Anomaly Troubleshooting SOP

Step one, first confirm the scope of the failure. Check whether the anomaly occurs on a single miner, a single rack, a single access switch, a single mine area, or the whole farm. If only one miner is abnormal, the problem is more likely from the miner's NIC, network cable, firmware, or configuration; if an entire rack is abnormal at the same time, check the corresponding switch and uplink; if the whole farm experiences high latency or disconnection at the same time, prioritize checking the egress, carrier, DNS, Proxy, and pool nodes.

Step two, compare local and pool data. At least view the miner's local hashrate, pool-side hashrate, Accepted Share, Rejected Share, Stale Share, online status, and reconnection records. Do not only look at the current instantaneous value; extend to 1 hour, 24 hours, and 7 days to observe trends.

Step three, check latency, packet loss, jitter, DNS, and routing. In addition to ordinary Ping, continuously record the latency distribution, packet loss rate, and routing path of different pool nodes. A normal single test cannot rule out nighttime congestion, intermittent carrier jitter, and cross-border routing changes.

Step four, check the mine's internal network equipment. Check whether switch ports have CRC errors, packet loss, negotiation anomalies, or ports frequently going up and down; check network cables, optical fiber, optical modules, and uplink bandwidth; check the CPU, memory, NAT session count, and connection tracking table of routers and firewalls; if a Proxy is used, also check the Proxy's connection count, processing latency, logs, and upstream pool status.

Step five, switch to backup pool addresses, ports, or regional nodes. When testing, change only one variable so that you can confirm whether the problem comes from the mine line, the pool node, or a specific port. Backup addresses cannot just be written into the configuration and never verified; you must periodically simulate a primary connection failure to confirm that miners can truly switch.

Step six, rule out pseudo network problems on the miner side. High temperature, frequency drops, hashboard anomalies, power fluctuations, frequent restarts, excessive overclocking, and firmware errors may all cause pool hashrate to decline or the reject rate to rise. This needs to be judged in combination with temperature, frequency, hardware errors, and restart records.

Step seven, establish continuous monitoring and automatic alerts. Relying on manually spot-checking a few miners each day cannot detect short disconnections and reject-rate spikes among thousands of devices in time. Mining farms should establish baselines and alerts for offline devices, low hashrate, rising reject rate, batch reconnections, and pool hashrate deviation.

How to Design a More Stable Mine Network

Backup pools are the most basic form of fault tolerance, but you cannot simply understand three pool addresses as complete network redundancy. If all three addresses are accessed through the same router, the same carrier line, and the same DNS service, then when the upstream line fails, all three addresses may become unavailable at the same time.

A more complete redundancy design includes at least dual carrier lines, egress equipment redundancy, reliable DNS, multiple pool regional nodes, backup ports, Proxy redundancy, and periodic failover tests. For large mining farms, the management network, miner network, and other business traffic should also be reasonably isolated to prevent system updates, video surveillance, or large file transfers from crowding out miner connection resources.

A local Proxy can reduce the complexity of miners directly establishing a large number of external connections and facilitate unified management of upstream pool connections, but the Proxy itself may also become a single point of failure. When deploying it, you need to evaluate its maximum number of downstream connections, CPU and memory load, task distribution capability, log storage, and fault recovery mechanism. The number and deployment location of Proxies should match the mining farm's scale, rack layout, and fault domains.

Stratum V2 attempts to improve mining communication efficiency, security, and task distribution methods at the protocol level. Its specification supports task distribution, Share submission, standard and extended channels, and mechanisms such as Future Job, where Future Job can distribute part of the task information in advance, reducing the time consumed by the upstream immediately generating and distributing new tasks after a new block appears.

Academic research also supports the basic direction that network latency affects effective hashrate and returns. One study, by measuring the block reception latency of major pools, points out that participants with the same physical hashrate may have different effective working time and returns because of different times of receiving new blocks; the study also emphasizes that network latency affects not only when miners start working on a new block, but also the competitive ability of blocks to be propagated and accepted. This type of research mainly analyzes block propagation at the pool and Bitcoin P2P network level, and should not be completely equated with the latency of a single ASIC submitting Shares to the pool, but both illustrate that mining competition is highly sensitive to communication timeliness.

How to Continuously Monitor Abnormal Miners and Effective Online Rate

When a mining farm has only a few dozen miners, operations staff can log into each dashboard one by one to troubleshoot. But when the scale expands to hundreds or even thousands, manual checking produces obvious information lag. The most effective management method is not to look for the cause after pool revenue declines, but to put offline devices, low hashrate, overheating, firmware, power mode, and pool status into a unified daily workflow.

In a mine management platform like Nonce, operations staff can query offline miners, low-hashrate miners, and overheating miners, and filter specific mining farms, racks, miner batches, or operating status through multiple conditions. The value of this is not to replace switches, routers, or professional network monitoring tools, but to help the team quickly judge the scope of the anomaly: whether it is a single miner, a certain rack, a certain workspace, or a large area of devices having problems at the same time.

For example, when a large number of miners in one rack go offline at nearly the same time while other racks are normal, the operations team can prioritize checking that rack's switch and uplink rather than restarting miners one by one. If only miners of a certain firmware version show low hashrate and high rejection, then firmware and operating mode should be checked first. If low hashrate is accompanied by high temperature, the problem may come from cooling and frequency reduction rather than the network.

For multi-farm operations teams, data comparison across workspace and mine dimensions also helps to judge whether a network anomaly is regional. The team can also establish anomaly alerts and standardized handling processes so that offline miners, low-hashrate miners, and batch anomalies enter the processing queue earlier. Nonce cannot directly repair carrier lines, nor can it replace a professional network performance monitoring system, but it can centralize miner status, batch queries, task processing, and operational data, reducing the time gap between a revenue decline and the discovery of abnormal devices.

The finance team should also incorporate effective online rate and reject rate into cost analysis. Simply using the miner's rated hashrate to calculate theoretical output will overestimate real earning capacity; a more reasonable method is to estimate output based on the pool's actual effective hashrate, online time, and accepted Shares, and then calculate the energy cost per coin. Only this way can one identify the real impact of network losses, equipment failures, and operational efficiency on mining costs.

Reducing Ineffective Hashrate Is the Only Way to Truly Reduce Cost per Bitcoin

The cost of an unstable mine network is often hidden. The meter is still running, the miner dashboard still shows hashrate, and there is no obvious power outage on-site, but the pool-side effective hashrate and actual revenue may have already declined. Compared with a complete network outage, latency jitter, intermittent packet loss, frequent short reconnections, and a long-term elevated reject rate are more easily ignored, because they do not immediately turn all devices offline.

To reduce real mining costs, a mining farm cannot only optimize electricity prices and miner energy efficiency; it also needs to reduce the hashrate that has already consumed electricity but has not formed effective revenue. Stable pool connections, reasonable network redundancy, timely anomaly alerts, and accurate effective-online-rate statistics are all part of cost control.

For operations teams, the ultimate measure of network stability is what proportion of time the miner continuously receives effective tasks and submits qualifying Shares to the pool in time. Only effective work confirmed by the pool truly has a chance to be converted into revenue.