Three steps to find out whether distance is costing you anything.
Step one runs in this browser and takes about five seconds. Step two is a small script you run at home. Step three is reading the answer without kidding yourself.
- 01Time one trip5 seconds
- 02Run the real check10 minutes
- 03Read your numbersa minute
Before you start, here is the loop you are measuring. Somewhere in the world a block gets found. The pool hears about it, builds a fresh puzzle, and pushes it out to your miner. Your miner drops whatever it was working on and starts the new one. Anything it sends in after that switch is work on a puzzle somebody already solved, and it counts for nothing. That handoff is the only place distance can cost you, and it comes around about once every ten minutes.
Twelve requests, back to back. The fastest one is the cleanest read on the path, because every sample carries your own machine’s noise on top of the real distance and never below it.
What you just timed is a web request to this site, the same kind of request that loaded this page. It is not your miner’s connection, and the machine serving this page is not always the machine your miner connects to. Browsers are not allowed to open the kind of connection a miner opens. That is not a limitation we chose, and it is why step two exists.
Here is one block of mining time, empty. Time your own trip above and this bar draws it — magnified, because a real trip is far too small to see against a block otherwise.
Run the real check on your own network
This is the measurement a browser cannot make. It is one Python file, about 14 KB, with nothing to install. It opens the same kind of connection your miner opens, asks for work the way your miner asks, and times every stage of it.
You need Python 3. macOS and most Linux machines already have it. On Windows, install it from python.org and tick the box that says Add to PATH.
Run it on the same internet connection your miners are on. Your home wifi is fine. A laptop tethered to your phone gives you your phone’s answer, not your miner’s.
It asks for a payout address because that is how a miner introduces itself. There is no signup, no key, and nothing to create. The script only ever talks to the destinations you type on the command line.
curl -O https://nexuspool.io/np-stratum-probe.py python3 np-stratum-probe.py --addr YOUR_ADDRESS solo.nexuspool.io:3350
python3 np-stratum-probe.py --addr YOUR_ADDRESS --tips 3 solo.nexuspool.io:3350 other-host:port
Point it at more than one destination and it sits and waits for a real block, then reports who handed out fresh work first. Same machine, same clock, same block, so there is nothing to take on faith. It ships with no list of pools and recommends none.
Read your numbers
The probe prints one row per destination. Three of these columns are plumbing. One of them is the answer.
- DNS
- looking up the name. Happens once, at start.
- Connect
- opening the connection. Once, at start.
- Handshake
- your miner introducing itself. Once, at start.
- WORK
- the pool hands over a puzzle. This one repeats, and this one is the answer.
The first three happen when your rig plugs in and then never again while it mines. If you take one thing off this page, take that.
- Under a secondnothing to do.
- One to five secondsstill nothing to do. You could not measure the difference over a year of mining.
- Twenty seconds or more, block after blockthat is real, and that is worth acting on.
We timed 162 new blocks on one of our servers over 26 hours, all on mainnet. Once our node saw a block’s header, we had fresh work on that block ready for miners in 0.49 ms, median. The slowest took 2.1 ms.
Each time, we had the work ready before our node finished validating the block: 162 out of 162, with a median lead of 205 ms. All 162 blocks passed validation afterward. The first work we hand out holds no transactions yet, so if your miner finds a block on it, you get the subsidy without the fees. We swap in the version with transactions when validation finishes.
We measured all of this inside our server. Step two times the trip from there to your miner.
So what do you do with this
If step two came back clean, you are done. Point a miner at the pool and leave it alone. Distance is not the thing standing between you and a block.
If it came back slow, look at your own side of the wire first. The wifi hop between the rig and the router, the router itself, anything doing traffic shaping on the way out. A pool cannot make your local network faster, and moving to a closer one will not fix it either.
If it came back slow against us and clean against somewhere else, that is a bug on our side. The probe’s output is the entire bug report. Bring it to the forum and we will go look.
- Host
- solo.nexuspool.io
- Port
- 3350
Questions people actually ask
Less than almost anyone assumes. The introduction between your rig and the pool is paid once, when it connects, and never again while it mines. The only latency that costs you is the one-way trip of a fresh puzzle after a block is found, and that is a sliver of a ten-minute gap. We measured it on a desk-sized miner: a 274 ms difference in distance came to roughly ten satoshis a year. The odds of hitting a block come from network difficulty and how fast your machine hashes. Neither one has a distance in it.
No. The latency that costs you runs from the moment someone finds a block to the moment fresh work reaches your rig. The pool spends part of that time hearing about the block and building the work, and distance adds the one-way trip to you. On our side, once our node sees a new block's header, we have the work ready in 0.49 ms, median, across 162 mainnet blocks we timed in September 2026. With the probe on this page you can time the whole handoff from your own network.
No. Miners and pools talk over a raw connection that browsers are not permitted to open, so no web page can perform that handshake or time when a rig actually receives work. A browser can time an HTTP request, which shows you the rough shape of the path and nothing more. That is what step one on this page does, and it says so. Step two is a small script with no dependencies that you run on the same network as your miners, and that one measures the real thing.
Run the probe from the same connection your miners use, pointed at the host in step two. It reports where every millisecond went: the name lookup, the connection, the introduction, and the moment usable work actually arrived. Give it two or more destinations and it races them over the same real block from your own machine, so the comparison does not depend on anybody's clock being right. It ships with no pool list and recommends nothing.