Latency
Illustrative event times: an order leaves at 12:00:00.000, the server receives it at .020, fills it at .045 and confirmation returns at .070. End-to-end confirmation delay is 70 ms; server processing here is 25 ms. These figures are a model, not a provider benchmark.
Measure a specific interval
Network ping, time to acceptance, time to fill and time to final confirmation answer different questions. Synchronised clocks and a recorded measurement method are necessary when combining client and server timestamps. One-way delay cannot reliably be inferred as exactly half a round trip when routes or processing are asymmetric.
Average and adverse delays
Report a distribution, such as median and high percentiles, together with failed requests and observation conditions. A fast average can conceal rare long pauses. Faster receipt can reduce exposure to moving quotes, but the available size, order type, checks and execution mode still determine the outcome.
Use timing for diagnosis
Log identifiers, reference Bid/Ask, requested quantity and fills. After a lost response, reconcile account state before retrying: an executed order can exist even when confirmation has not arrived. Moving software to a VPS can change some delays but cannot guarantee a fixed speed or remove gaps, provider outages and liquidity constraints.
FAQ
Is a 5 ms ping a 5 ms execution time?
No. It measures a particular network round trip, not the complete order-processing and execution lifecycle.
Does a delayed confirmation prove the order did not execute?
No. Check order identifiers, executions and the position state before retrying.
