Measure the Stratum exchange your miner uses
Start a timer just before the miner sends mining.submit and stop when its matching server response arrives. This client-visible round trip includes the network path and the server response. Sort samples from the same test: p50 is the median and p95 is the 95th percentile. Record the sample count, UTC window, endpoint, port and transport, miner and firmware, ISP and local network, plus accepted or rejected outcomes. These are measurement instructions, not reported latency results.
- Measure mining.submit request-to-response time, not ICMP ping, DNS lookup or website load time.
- Keep endpoint, transport, firmware, local network and test window consistent when comparing routes.
- Report the sample count and accepted or rejected outcomes with p50 and p95.
- If firmware does not expose share timings, use a timestamping Stratum client on the same route and identify it as a separate measurement.
Read p95 beside stale-share outcomes
A lower or steadier response time can reduce client-visible delay while a miner sends work and receives updates; a high p95 reveals spikes hidden by the median. This may help limit time spent on outdated work when communication delay is a cause, but it does not change Bitcoin's target or the miner's hashrate and does not guarantee fewer stale shares. Compare rejection reasons under the same device and route conditions.
- Compare p50 and p95 with the same miner, transport and local network.
- Track stale responses separately from duplicate, low-difficulty and authorization errors.
- Do not use a latency percentile alone to infer block odds or pool performance.
Check the original guidance: Bitcoin Developer Guide · Mining
Use the dashboard to confirm activity, not timing
Dashboard statistics and individual Stratum replies can update on different schedules. A delayed chart alone does not show whether recent work was accepted. Check a recent job, its share response and reconnect timestamps in the miner or pool logs. If those details are unavailable, do not infer share latency from the dashboard.
- Persistent connections avoid reconnecting for every job or share.
- Statistics are processed separately from the mining exchange.
- Use recent accepted responses and timestamps to confirm activity.
Pair regional access with the right miner settings
Connect to btc.solomining.xyz:1313 for TCP, or btcssl.solomining.xyz:1414 if your installed firmware supports Stratum over TLS. Use your own Bitcoin address and a unique worker name. Stable local networking and correct firmware settings help you benefit from the service's regional access; a low latency figure cannot repair an invalid address or unstable hardware.
- Match the host, port and transport to your firmware.
- Keep the miner's local network stable and follow documented reconnect behavior.
- Verify accepted work before moving more devices to the connection.
Interpret timing with actual share responses
The mining endpoint and the route from your own network determine what your miner experiences. Record repeatable submit/reply samples and accepted or stale outcomes before deciding whether a route change helped. This page has no global or device-specific latency measurements; it provides a method for making and comparing your own measurements.
Content updated: 3 October 2026 · Measurement guide checked 3 October 2026. No regional or global latency values are claimed.
Questions about low-latency solo mining
What do p50 and p95 mean for a Stratum connection?
Measure the time from sending a mining.submit request to receiving its matching response. The p50 is the median sample; p95 is the value below which 95% of the recorded samples fall. Include the sample count and test conditions so another route can be compared fairly.
Does this page publish a measured latency for each region?
No. A useful result depends on the miner's location, ISP, route, endpoint, transport and local network. Measure Stratum submit/reply timing from the miner or a clearly identified test client, then report the sample count and conditions.
Does lower latency make a valid hash more likely to find a block?
A shorter, stable route can reduce communication delay for job updates and submissions, which may reduce stale work when network delay is the cause. It does not change the network target or physical hashrate and does not guarantee fewer stale shares or a block. Compare stale responses under matching conditions.
Is a fast dashboard the same as a fast mining connection?
No. Website loading and mining communication use different paths and measurements. SoloMining keeps statistics processing separate from the Stratum exchange. Check the miner's connection, incoming jobs and accepted responses rather than using webpage load time as a mining-latency measurement.
How do I start using the connection?
Use the published TCP endpoint or the TLS endpoint supported by your firmware. Enter your Bitcoin receiving address and a unique worker name, then verify recent accepted work. The connection guide provides the fields; the Bitaxe guide generates the separate host and port settings used by AxeOS.