Shares and Latency: Understanding ASIC-Pool Communication

A share is a proof of work submitted to the pool: a header hash that beats the assigned share target, which is easier to hit than the network target. The pool uses shares to count your work. Latency is the round-trip and processing time between your machine and the job server. The two meet on one point: a job that has grown too old by the time your share arrives earns nothing.

Jobs, invalidation, and the two clocks that matter

The pool sends a job, meaning a template holding transactions, extra-nonce, nBits, and the rest. When the network or the pool advances, through a new block or a new template, previous jobs go obsolete. A share computed on an expired job no longer contributes to the count, or contributes less depending on pool rules.

Two clocks determine that loss:

• RTT, the network round-trip, plus the controller's own queues;
• job lifetime, set by block arrival, ten minutes on average but with heavy variance, and by the pool's clean-job policy.

Block arrival is entirely out of your hands. The network path, the choice of point of presence, and to a lesser degree the firmware and its submit strategy, belong to you.

Accepted, stale, rejected

Dashboards generally distinguish three states:

• accepted: valid share on a job still current, counted;
• stale, sometimes late: a correct proof computed on a job that is too old;
• rejected: malformed share, target not met, unknown worker, duplicate, or a pool-specific rule.

Those labels are not standardized, and what one pool calls a reject another calls a stale. Read your pool's legend before any comparison. A non-zero stale rate is expected, since blocks keep arriving; what should alert you is a sharp gap against other machines on the same site and the same pool.

Be wary of reference rates quoted without measurement: values depend on RTT, pool, firmware, and short-window variance. A "normal rate" asserted without measuring your link tells you nothing about your fleet.

Why latency costs money

While the machine works on a job that has already been replaced, its hashes stop producing useful shares. The fraction of time spent off-template grows with the delay needed to receive the new job and drop the old one. The relationship is not linear, blocks being a random process, but the direction holds: higher RTT and jitter mean a larger share of dead work.

Latency also weighs on short-run apparent luck and, for a fleet large enough to find blocks, on orphan risk through propagation. For small pool hashrate, the dominant effect remains stales and rejects by a wide margin.

What drives latency up

• A distant pool server, on another continent or behind poor peering.
• A VPN, a proxy, a saturated NAT, Wi-Fi or powerline on the control plane.
• A controller CPU saturated by a heavy interface, logs, or several badly managed pools.
• Packet loss, which triggers retransmission.
• A heavily drifted system clock, which produces rejects carrying a "time" reason.

A badly tuned failover, too jumpy or too slow, also generates bursts of stales at each switch.

What a share is not

A share is not a satoshi. Going from share to payment depends on the payout scheme, FPPS, PPLNS, or another, and on pool fees. A spike in share count does not prove the machine mines better if share difficulty dropped at the same moment.

The comparison that means something is between effective hashrate, computed from shares and share difficulty, and the hashrate reported by firmware. A persistent gap between them gets diagnosed; it does not get compensated.

The five measurements to take together

Over a single time window, record: RTT to the stratum server actually in use, the accepted, stale, and rejected rates, job height, pool-side hashrate, and machine-side hashrate. Those five values taken together identify the cause; taken separately they nearly always point at the wrong one.

Then change one variable at a time: the pool's geographic URL, the cable, or the backup pool. And always keep a failover configured, on a single agent, so an outage on the pool side does not turn into hours of lost hashrate.