How to Test Pool Endpoint Latency Before Mining

A low ping to a pool is useful. It is not the number that decides whether your rig works on the next block quickly. To test pool endpoint latency, measure the path your miner actually uses: a TCP connection to the mining port, then the time from a new job leaving the pool to your rig receiving it.

Those are different measurements. The first tells you whether distance, routing, or a local network problem is adding delay before a session begins. The second tells you whether your miner can stop hashing old work when Bitcoin moves to a new block. Neither changes your chance of finding a block. Network difficulty sets those odds at every pool. Latency only affects how much time a rig may spend on work that has already become old.

For Bitcoin on NexusPool (nexuspool.io), the endpoint is solo.nexuspool.io:3350. It accepts Stratum V1 and encrypted Stratum V2 on the same port. The address steers a miner toward a nearby healthy region. Test that address from the same network your miner will use, not from a phone on cellular data or a cloud server in another city.

What endpoint latency measures

Endpoint latency starts with the round trip between your network and the server that accepts your mining connection. A TCP connection test includes the route used for the actual port, which makes it more useful than an ICMP ping alone.

It does not measure the whole mining path. It does not show how long your rig takes to process a job. It does not show Wi-Fi pauses inside your house. It does not show whether your firmware has a queue, whether a proxy is buffering messages, or whether a new Bitcoin block has reached the pool's node yet.

That limit matters. A 20 ms ping can coexist with a slow job change if the local network is congested or the miner is busy. A 100 ms round trip can still be ordinary for a miner far from the pool regions. Distance changes when work reaches the rig. It does not change the odds attached to the rig's hashrate.

Start with a TCP connection test

Run the test from a computer connected to the same router as the miner. Wired is preferable for the test. If the rig uses Wi-Fi, repeat it from a device on that same Wi-Fi network as well.

On macOS, Linux, or Windows with Python installed, save this as latency.py:

import socket
import time

host = "solo.nexuspool.io"
port = 3350

started = time.perf_counter()
sock = socket.create_connection((host, port), timeout=10)
elapsed = (time.perf_counter() - started) * 1000
sock.close()

print(f"TCP connect: {elapsed:.1f} ms")

Then run:

python latency.py

Run it repeatedly at a few different times. Keep the results. You are looking for the usual result and the bad result, not a single flattering number.

A connection time that stays in a narrow range usually points to a stable route. Occasional large jumps can point to Wi-Fi interference, a loaded router, bufferbloat from an upload, or routing outside your home. A timeout is not an endpoint latency reading. It means the connection did not complete within the limit and should be investigated as a connectivity problem.

A basic ping can still help identify local trouble. If ping times rise whenever someone uploads video or backs up a computer, the bottleneck may be inside the home. But do not treat ping as a verdict on the mining port. Networks can handle ICMP differently from TCP, and some servers de-prioritize or block it.

Test from the miner when possible

The best test runs on the miner itself. Many small ESP32-class miners do not offer a shell, so that is not always practical. In that case, use a laptop on the same access point and keep it close to the rig's network conditions.

Do not test from a wired desktop and assume the result belongs to a Bitaxe on a crowded 2.4 GHz Wi-Fi channel. The desktop measured Ethernet. The miner has to live with the radio link, retransmissions, and power-saving behavior of its own connection.

For a standard ASIC, the management interface may expose a ping utility or connection logs. Use those for comparison, but favor a test to port 3350 over a hostname-only test when the firmware permits it.

Measure new-work latency, not just the handshake

A mining connection remains open. The TCP handshake happens once, while job messages arrive throughout the session. The measurement that matters after connection is the delay between a new job being sent and your rig accepting it.

Some firmware shows job timestamps, block-height changes, or Stratum messages in its log. If yours does, watch the log across a Bitcoin block change. Record the timestamp for the new job at the rig. Then compare it with a timestamp from another device on the same network, or with the pool-side event if your monitoring setup provides one.

This takes more care than a connect test because clocks must agree. Set the miner, router, and computer to synchronize time. A clock that is two seconds wrong can turn a good handoff into a fake two-second delay.

If you run a Stratum proxy, measure on both sides of it. First measure from the proxy to the pool. Then inspect when the proxy passes a new job to the miner. That separates Internet delay from a local device that is holding messages. It also prevents a common mistake: blaming a distant endpoint for a delay introduced by equipment on the same shelf.

NexusPool prepares work on a new Bitcoin header before its node finishes validating the block. On the Frankfurt server, the median time from header to work was 0.49 ms on September 10 and 11, 2026. That first job has no transactions. The pool sends later work after validation with transactions included. This is pool-side timing, not a promise about the time to your rig. Your own route and local network are still part of the result.

Know what a high result means

There is no universal number at which a mining endpoint becomes unusable. A miner in a location far from Los Angeles, Chicago, Frankfurt, and Singapore will have a longer round trip than one near a region. That is physics and routing, not evidence that anything is wrong.

What deserves attention is change. If your usual TCP connection time doubles after moving a rig to Wi-Fi, test the Wi-Fi. If it jumps only during household uploads, address queueing in the router. If only one miner lags, inspect that miner's signal, power supply, and firmware. If every local device shows a different route or recurring failures, collect timestamps before drawing conclusions.

Do not confuse a stale-share statistic with endpoint latency either. A stale or rejected share can have several causes. The pool needs to read the submitted share, compare it with the assigned work, and return the reason it has. A job change is one part of that path. An invalid nonce, an old job ID, an incorrect difficulty target, or a delayed local submit can produce a similar-looking result.

Test after changing the connection path

Retest after changes that can alter routing: moving a miner from Wi-Fi to Ethernet, adding a proxy, changing an ISP router, enabling a VPN, or relocating the hardware. A VPN often adds distance and another queue. It can be useful for privacy needs, but it is not a free latency improvement.

Also retest after a miner firmware update. Firmware can change reconnect behavior, message handling, and how it reports time. The connection address stays simple: use your Bitcoin address as the worker identity and point the rig to solo.nexuspool.io:3350.

Endpoint latency is a measurement, not a scorecard. Measure the TCP port from the network your miner uses. Watch how quickly that miner receives new work. Then fix the part of the path your results actually identify. Trust nothing. Verify the handoff from your network.