Trading latency is elapsed time between specified events on a trading path. A difference between timestamps measures that elapsed time only after the timestamp locations and clock errors are accounted for.

Timestamp locations on the trading path

A network-interface timestamp, a kernel timestamp and an application receive timestamp mark different events. Linux exposes hardware timestamps separately from software timestamps. An application measurement can include processing that a hardware arrival timestamp precedes.

The measured interval must therefore name its start and end. Market-data arrival to order submission is different from client request to venue acknowledgement. A garbage-collector pause is a component event, not the elapsed time of the whole order path.

A change in timestamp placement can change the reported number without making the physical path faster. Comparing measurements across systems requires equivalent event boundaries before comparing their values.

Clock offsets in a one-way measurement

Let actual one-way delay be d. Let the receiver’s clock offset from the reference be r, and the sender’s offset be s. Subtracting the sender timestamp from the receiver timestamp gives d + r − s when the timestamp locations otherwise match the intended events.

Take an actual delay of 40 microseconds, receiver offset of +15 microseconds and sender offset of −5 microseconds. The measured difference is 40 + 15 − (−5), or 60 microseconds. The additional 20 microseconds comes from relative clock offset, not packet transit.

If the possible relative offset is bounded, the elapsed-time result can carry that bound. Without an established bound, extra decimal places do not supply accuracy. Clock synchronization and timestamp resolution answer different questions.

Resolution, accuracy and drift

Resolution is the increment a timestamp representation can express. Accuracy concerns agreement with the reference event or time under the measurement method. Drift changes a clock’s offset over time. Holdover behavior describes what happens when the normal timing reference is unavailable.

The Precision Time Protocol, or PTP, supplies a synchronization mechanism; LinuxPTP implements it using relevant Linux interfaces. Installing the implementation does not establish a universal accuracy value for a particular network. Hardware support, reference quality and path asymmetry remain part of the measurement conditions.

A timing record needs the synchronization state during the measured interval. A calibration made before a reference outage does not establish the later offset without a justified holdover model or new measurement.

Latency distributions under load

A median describes the middle of a measured population. A high percentile describes a different part of that population. Lower median latency can coexist with worse delays during bursts or recovery.

Packet size, arrival rate, queue buildup, CPU allocation and timestamp loss affect what population the measurement represents. Dropped requests cannot disappear from the assessment merely because they have no successful completion timestamp. Their absence changes the result being summarized.

A comparison of implementations therefore fixes the workload and correctness conditions, measures the same event boundaries and reports the relevant distribution with timing uncertainty. Clock-rule compliance, where applicable, is a separate scoped question from whether a trading service meets its performance objective.

What changes is the path and measurement arrangement. The stable requirement is an explicit interval, an identified population and a justified account of clock error.

Questions about clock offset

Does nanosecond timestamp resolution prove nanosecond accuracy?

No. Resolution describes representable increments; clock alignment and timestamp placement determine accuracy.

Does a lower median prove better latency for every order?

No. Tail delays, burst behavior and the population of failed or missing operations require separate measurement.

Does installing PTP establish a latency guarantee?

No. Synchronization needs measured deployment-specific evidence, and application latency includes other components.