Latency Measurement: From Client Action to Execution Report

Draw one request path before collecting numbers

Assign a correlation identity to the request and related acknowledgments or executions. Name the observation points: client action, outbound send, gateway receipt, validation complete, upstream send, upstream response, client receipt and screen update. A single order can receive several reports; decide whether the measurement ends at acknowledgment, first fill, final fill or another explicit event.

Keep transport delay, application processing and waiting for an execution outcome conceptually separate. An unfilled limit order does not have the same completion meaning as a market order acknowledgment. Record instrument, order type, route and session conditions so the sample can be interpreted without guessing what finished.

Use clocks that support the interval

Measure elapsed time within one process using an appropriate monotonic clock. Python's time documentation explains that monotonic readings do not move backward with system-clock updates and only differences between readings are meaningful. They are not portable wall-clock timestamps to subtract across arbitrary hosts.

Cross-host intervals need synchronized clocks and a recorded error bound or uncertainty. If one host may be several milliseconds ahead, a smaller claimed network interval is not defensible. Keep wall-clock timestamps for correlation, monotonic durations for local timing and synchronization status for interpretation. Do not repair negative intervals by silently taking their absolute values.

Compare distributions and outcomes

Separate successful outcomes, rejections, timeouts and unfinished requests. A fast error is not a fast successful trade. Report the observation window, request count, median and relevant tail percentiles for a clearly defined population; a mean can hide a small group with long delays.

Use the same boundaries when comparing runs. A browser measurement over a user's network cannot be compared directly with an internal gateway timer as if the difference represented one supplier's improvement. Inspect queue age and resource pressure when tails lengthen. This page describes a measurement method, not a location ranking or a promised execution speed.

Worked example: one end-to-end interval

In a fictional synchronized trace, client send is at 0 ms, gateway receipt at 12 ms, upstream send at 17 ms, upstream acknowledgment at 31 ms and client receipt at 44 ms. The client-observed interval is 44 ms; the gateway-to-upstream-send segment is 5 ms. The remaining segments total 39 ms. A first fill received later at 90 ms is a different outcome and must not replace the acknowledgment endpoint without relabeling the metric.