Clock synchronisation breaks after the clock is right

Can we prove that the timestamp on this fill is close to UTC? Only if the system records more than a clock offset. A trading firm needs to know which clock produced the timestamp, what event it describes, how that clock was disciplined and how uncertain the measurement was. Many infrastructure teams monitor one offset value, see it near zero and assume the problem is solved. That is how clock errors make it into market data, order records and incident timelines.

Clock synchronisation is a chain, not a setting. It runs from the time source and network through the NIC, operating system, application and storage pipeline. Each step can add error or change the meaning of the time. A useful teardown starts by separating those failure modes.

Offset is not proof of synchronisation

An offset says how far a local clock appears to differ from a reference at a particular measurement point. It does not, by itself, prove that the reference is traceable to UTC, that the measurement path is symmetric or that the timestamp on a trade came from that clock. Nor does a low current offset show what happened during a network flap or a host pause five minutes earlier.

Network Time Protocol (NTP) is often adequate for services where millisecond-scale accuracy is sufficient. Precision Time Protocol (PTP) can provide tighter synchronisation, particularly when the NIC and network switches support hardware timestamping and the path is engineered for it. Neither protocol removes the need to check the entire chain. A PTP client using software timestamps can perform worse than a well-managed NTP host. A grandmaster disciplined by GNSS can lose that source, then rely on its oscillator in holdover. Its advertised status may remain healthy while its uncertainty grows.

Path asymmetry is another common blind spot. NTP and PTP estimate delay using traffic travelling in both directions. If those paths have different latency, the clock estimate inherits part of that difference.

Congestion, route changes, different switch queues or a badly configured boundary clock can introduce asymmetry. Monitoring only whether the daemon is synchronised misses the size and stability of the error.

Typical market ranges below are engineering ranges, not guarantees or audited results. Hardware, topology, load and configuration can move results outside them.

Timestamp placement changes the story

A timestamp is only useful if its event is defined. For a market-data packet, the NIC receive time, kernel delivery time, parser completion time and strategy decision time are different events. For an order, the time of creation, send, gateway receipt, venue acknowledgement and execution are also distinct. Labelling every one of them "exchange time" or "arrival time" makes later analysis unreliable.

Hardware receive timestamps can capture a packet close to the wire, before operating-system queues add variable delay. They do not tell you when the application acted on it. Conversely, an application timestamp can show decision timing, but includes queueing and scheduling delay. Keep both where latency analysis matters, and name each field for the event it measures. The same principle applies to execution reports received through a broker or venue gateway.

Use a monotonic clock for elapsed durations inside a process. Use UTC-referenced wall-clock time for external correlation and records that must be compared across hosts. Wall clocks can be stepped or slewed as they are corrected. A duration calculated by subtracting two wall-clock readings can therefore be misleading, especially around a step. Record the clock source, timestamp layer and relevant correction state alongside the measurement.

Leap-second handling deserves explicit treatment. Some providers smear the correction over a period; others do not. Hosts using different approaches can disagree even while each reports a healthy synchronisation state. Keep a consistent time policy across systems that need direct comparison, and document how feeds, gateways and log stores handle leap events.

Reconciliation should preserve uncertainty

Teams often try to reconcile timestamps by applying one fixed offset to an entire feed or host. That can hide the symptom while making the data less honest.

Clock error changes over time. A host may drift during holdover, recover after a source returns, or experience a step. A feed handler may also queue packets unevenly. One correction applied across the session cannot distinguish clock error from transport or application delay.

Store the observed offset and its uncertainty as a time series, not just as a current health value. Keep the source identity, stratum or grandmaster identity, sync state and any step or holdover events.

For important records, retain the original timestamp and a separately calculated reconciled timestamp. That lets an investigator reproduce the correction rather than relying on a mutable field.

When aligning events from two systems, compare their clock-error bounds as well as their displayed times. If host A is estimated to be within 2 μs of UTC and host B within 20 μs, a 5 μs difference between their records does not establish which event happened first. Represent the ordering as uncertain unless independent sequence numbers, venue timestamps or packet capture evidence resolve it.

• Keep raw timestamps immutable and store corrections separately.
• Attach the clock source, timestamp layer and uncertainty to each relevant data stream.
• Track offset, frequency adjustment, source changes, holdover and clock steps over time.
• Use sequence numbers and venue-provided timestamps as additional evidence, not substitutes for local timing.
• Make replay use the same timestamp semantics as live processing, or document the difference.

Test the failure modes, not just the steady state

A dashboard showing a green synchronisation status during quiet periods is a weak test. Load can expose interrupt delays, queueing and packet loss.

Network changes can alter path asymmetry. A grandmaster failover can shift the clock or increase uncertainty. Run tests that show how the system behaves under those conditions, then verify that downstream records retain enough information to interpret the result.

For operational coverage across broker platforms and supporting infrastructure, Trading Technology's infrastructure coverage tracks the systems and providers firms depend on. The clock itself still needs local measurement. Useful checks include:

• Compare host wall clocks against an independent reference, and compare the reference against the firm's chosen UTC source.
• Measure NIC hardware timestamps against kernel and application timestamps under representative packet rates.
• Test NTP or PTP source loss, grandmaster failover, network congestion and recovery from holdover.
• Check whether corrections slew or step the clock, and whether applications detect or record either event.
• Inspect logs and replay output for timezone conversion, precision truncation and inconsistent leap-second policy.
• Alert on offset and uncertainty trends, not only on loss of synchronisation or a single threshold breach.

PTP also adds operational dependencies. NIC firmware, drivers, switch configuration, multicast handling and the timing source all matter. Hardware timestamping can reduce uncertainty, but it increases configuration and monitoring work.

NTP is simpler to deploy and can be the right choice for applications with looser timing requirements. Choose by required accuracy and failure behaviour, then test the deployed path rather than relying on protocol labels.

Make timing an owned production service

Clock synchronisation often belongs to nobody because it crosses network, systems, application and operations teams. Assign an owner for the time source and distribution path, then define who responds when the source changes or uncertainty rises. Document which applications require hardware timestamps, which can tolerate millisecond accuracy and what happens to order flow if timing falls outside policy.

Set alert thresholds from the application's need, not from a convenient daemon default. A market-data strategy that compares events across co-located hosts may need tighter bounds than an administrative log service.

Thresholds should include duration and rate of change. A short excursion may be recoverable; a persistent drift or unknown reference should trigger investigation. For regulated records, confirm the applicable jurisdictional requirements for UTC traceability, timestamp granularity and retained evidence rather than treating a vendor configuration as proof of compliance.

Run a periodic reconciliation drill. Pick a sample of packets, decisions and execution reports, trace their clock sources and timestamp definitions, and reproduce the correction from stored offset history.

If the exercise needs an undocumented constant or an engineer's memory, the audit trail is incomplete. Broker infrastructure reporting at Trading Technology can provide context on platform changes, but the evidence has to come from the firm's own hosts and records.

Before the next release, check the measured 99.9th-percentile UTC offset under peak load against your own limit, starting with 100 microseconds.

#sincronización del reloj de trading #conciliación de marcas de tiempo #marcas de tiempo por hardware #supervisión de infraestructuras de trading #NTP para sistemas de trading #PTP clock sync #UTC timestamping #MiFID clock synchronisation