Mining Latency is the elapsed delay of a specific mining step: work distribution or activation, delivery of a discovered share, or candidate-block propagation. A value must identify its measured endpoint events and observation conditions.
Stratum V2 distinguishes work distribution from result submission. Time from sending a job to receiving it is not time from receipt to the ASIC actually switching; returning a share to the pool is another path. For your measurements, define both endpoints and correlate records using channel_id and job_id. [Stratum V2 — Mining Protocol]
Braiins describes ping as a reachability test. Its RTT includes outbound and return travel; automatically dividing by two does not measure one-way latency because the directions may be asymmetric. Ping also does not measure job construction, proxy queuing or device activation. Comparisons require the same traffic type and endpoints. [Braiins — Connection diagnostics] [RFC7679 — One-Way Delay Metric]
RFC7679 requires one-way measurements to account for clock synchronization and timestamp location. Illustration: Tsend = 1000 ms and Trecv = 1040 ms yield 40 ms only with comparable clocks. A receiver clock offset of 30 ms changes the interpretation. Without an uncertainty estimate, a difference between servers is not a demonstrated speedup. [RFC7679 — One-Way Delay Metric]
In Stratum V2, a Future Job can arrive early; the matching SetNewPrevHash with job_id activates it. Therefore also measure activation delay, not just template download. A non-empty prepared job may contain a transaction already included in the new block; faster distribution does not justify ignoring that conflict or mining an invalid block. [Stratum V2 — Mining Protocol]
Stratum V2 permits batched SubmitShares.Success. Waiting for a response can therefore include intentional batching; it is neither pure network time nor proof that the share awaited acceptance for that entire period. SubmitShares.Error may arrive after delayed validation. Match sequence_number and distinguish sending, receipt, validation and acknowledgement. [Stratum V2 — Mining Protocol]
In high-bandwidth mode, BIP152 sends cmpctblock without a preceding request. If the receiver lacks transactions, getblocktxn and blocktxn add another exchange. This is block relay between nodes, not a measurement of share submission. Less transferred data guarantees neither zero delay nor a substitute for full validation. [BIP152 — Compact Block Relay]
RFC7679 defines a time limit Tmax and treats an undelivered packet as an undefined delay; its defined percentile orders such values as infinitely large. For your own p50/p95, report the methodology, sample count and losses. Excluding all timeouts can make results look better; an empty sample is not zero latency. [RFC7679 — One-Way Delay Metric]
When changing a route or setting, retain comparable devices, time windows and measurement definitions. Separately track job_id activation, work acknowledgements, rejection reasons and outages; do not confuse lower ping RTT with a demonstrated reduction in every delay. This is a comparison method, not a promise of finding a block or a universal safe limit in ms. [Stratum V2 — Mining Protocol] [Braiins — Connection diagnostics] [RFC7679 — One-Way Delay Metric]
For the clearest picture, read this entry together with Stale Rate, Block propagation, Stratum V2, Mining Pool. The reverse links also lead from Stale Rate.