Comparing Mining Pool Regions: Latency, Stale Shares and a Fair Test

A pool’s office location does not tell you which Stratum endpoint works best from your mining farm. Compare the actual connection from your site instead of assuming that one continent always offers better mining results. This guide explains a repeatable test of pool regions without changing your ASIC configuration at the same time.

Identify the endpoint you are testing

Use the pool’s current connection instructions to identify the hostname, port, algorithm and worker format. The company address, payout service and Stratum server may be in different places. If your farm uses a proxy, include that proxy in the test plan.

Keep the primary connection and backup behaviour visible in your records. A worker that moves to another provider during the test may credit part of its work to a different account. Do not treat that as missing hashrate without checking the backup configuration.

Measure from the mining location

Test from the farm’s network rather than from a computer in another country. Ping can help identify latency or packet loss when ICMP is supported, but it does not prove that a Stratum session is healthy. A server can also reject ping while accepting mining connections.

Record repeated observations at different times. Combine network measurements with connection resets, accepted shares, stale shares and the worker’s availability. Physical distance is only one factor; routing and network congestion can change the result.

Keep the equipment and observation window comparable

Use one ASIC or a matched group. Keep firmware, power mode, clock settings, internet provider and cooling conditions unchanged while comparing regions. Allow the pool’s averaging window to fill before interpreting a difference in displayed hashrate.

Use the same observation length for each region and mark interruptions separately. If practical, repeat the comparison by swapping matched groups between endpoints. A short test during an outage is not evidence that an entire continent performs worse.

Compare credited work and connection stability

Record the endpoint, period, accepted and rejected shares, stale shares, worker downtime and average pool-side hashrate. Keep credited rewards separate from completed wallet payouts. The payout threshold and accounting model affect when a payout appears.

No universal percentage of lost revenue can be calculated from a single ping value. If the apparent result is small, repeat the test and check whether hardware faults, restarts or a changing network path explain it. For other selection criteria, use the Bitcoin mining pool comparison.

Choose a stable route and verify failover

Prefer an endpoint with stable connectivity and reproducible results. Confirm the documented behaviour of your ASIC’s backup pool slots: several fields often specify failover priority rather than an equal split of work. Test a small group before changing a whole farm.

Save the original configuration and define how to return to it. The step-by-step pool connection guide explains worker configuration and checks after a change. Re-test the chosen region if the site’s ISP or routing changes.