Mining Latency

The pool prepares work for Petr and sends it to mining software. The software may pass the message through an intermediary, a proxy, to an ASIC, a chip designed for mining. What matters is the actual switch to new work, not just a message reaching a computer. The machine then submits shares, partial results demonstrating work to the pool. In Stratum V2, the protocol governing communication between mining devices, channel_id and job_id associate messages with the right channel and job. Without that connection, we might time the start of one job against the end of another. [1]

Petr tries ping following Braiins diagnostics. It tells him whether the server responds and how long a request and its reply take to travel there and back: RTT, or round-trip time. This is a useful first step. But the two directions may follow different routes and experience different queues, so dividing by two does not measure one-way delay. Ping also does not show how long the pool takes to prepare work or the ASIC takes to start it. A good result can therefore coexist with slow job switching. [2] [3]

In our example, the sender records Tsend = 1000 ms and the receiver Trecv = 1040 ms. The difference is 40 ms, but the receiver’s clock could be ahead by 30 ms. Simple subtraction would then not give the true transmission time. The unit ms means milliseconds, thousandths of a second. The network measurement standard RFC7679 therefore considers clock synchronization uncertainty and where timestamps are taken. Without that information, a difference between servers is not demonstrated speed improvement; it may merely reflect differently adjusted clocks. [3]

To avoid waiting for a complete job after a new block, Stratum V2 permits a Future Job to be sent in advance. It is work prepared for a future chain connection, not an instruction to start immediately. SetNewPrevHash activates it with the correct previous-block reference and matching job_id. If the prepared work includes transactions, the new block can make some of them unsuitable for reuse, for example because it already includes them. Reducing latency does not justify ignoring that conflict. Quickly starting incorrect work is not a useful saving. [1]

Petr sees a share leave, but its acknowledgement arrives later. In Stratum V2, SubmitShares.Success can summarize several accepted shares at once; deliberate batching reduces message traffic. The entire wait cannot therefore be attributed to transmission or taken to mean the pool knew nothing of the result throughout. SubmitShares.Error may also follow later validation. sequence_number helps associate replies with submitted results. Troubleshooting should distinguish receipt, checking and notification. [1]

Mining also depends on quickly learning that someone has published a block. This is a different stage from the machine-to-pool connection. BIP152 reduces the data sent between nodes: in high-bandwidth mode, a node can directly send cmpctblock, a compact description of a block. The receiver fills in most transactions from its own data. It requests missing ones with getblocktxn and receives them in blocktxn, potentially adding another exchange. Fewer bytes do not mean no waiting and do not replace full validation, checking all the block’s rules. [4]

Petr cares about ordinary operation and occasions when something gets stuck. p50/p95 are percentiles: they describe different parts of the distribution of measured times, rather than a single average. When times are sorted from shortest to longest, p50 sits roughly in the middle and p95 near the slower end: about 50% of values fall below the first threshold and 95% below the second. This helps distinguish typical waits from long delays. But the treatment of undelivered messages must be stated. RFC7679 uses a waiting threshold, Tmax; exceeding it is not an ordinary quick measurement. In its percentile calculation, undefined delays are ordered as infinite. Silently dropping them would improve the picture only on paper. An empty sample is not zero latency either: it means there is no basis for a conclusion. [3]

Petr compares the same stages under similar load and over equally long periods. For each measurement in ms, he records the timestamp location, clock uncertainty and relevant job_id; he keeps ping and RTT separate. He adds outages and rejected results so a fast average cannot hide unreliability. He can then investigate whether another server, network or machine setting would help. The aim is less time on outdated work, not a promise of finding a block. Low latency changes neither mining’s randomness nor validity rules. [1] [2] [3]