Plataformas · Software · Proveedores · Mercados
A serious timestamp failure can cost a broker or prop firm £10,000 to £100,000 in investigation, client remediation and disrupted trading. That is a planning range, not a fixed tariff: the bill depends on incident duration, affected flow and the evidence available. A clock that is milliseconds out can make an order appear to precede a market event, obscure a latency spike or leave operations unable to establish which system acted first.
The fix is not simply to install Precision Time Protocol (PTP). Teams need to define which clock each timestamp represents, measure offset at the point of use and preserve enough information to reconstruct time after a fault. The same discipline helps with regulatory records and internal execution analysis. For related infrastructure coverage, see Trading Technology.
Start with the cost and the failure mode
Clock offset is the difference between a system clock and its reference at a given instant. Drift is the rate at which that difference changes. A host can show a small offset during a check, then drift during a busy period, after a virtual machine migration or when a time source disappears. Record both offset and source health over time.
Trading systems also mix different kinds of time. UTC wall-clock timestamps support cross-system ordering and audit.
A monotonic clock measures elapsed time without jumping when wall time is corrected. Use monotonic time for durations such as strategy processing or gateway queue delay. Keep wall-clock time for event records, but do not calculate latency by subtracting timestamps from unsynchronised machines.
Before setting targets, map the timestamps in the order path: market-data event, network-interface receive, application decode, strategy decision, order send, exchange acknowledgement and client report. A field called "time" is not enough. Document its clock source, capture point, unit, precision and whether it is generated in hardware or software.
Choose a time architecture and define its limits
For latency-sensitive systems, PTP with hardware timestamping is the usual choice on controlled network segments. A grandmaster provides the reference; boundary clocks in switches reduce timing traffic and distribute time to hosts. NIC hardware timestamps capture packets closer to the wire than application timestamps. Check that switches, NICs, drivers and operating-system services support the same PTP profile and domain.
GNSS can provide a useful reference, but it is not a complete resilience plan. Antenna faults, signal interference, receiver failure and holdover quality all matter. Use monitored redundant sources where practical, and test what happens when the primary grandmaster is lost.
A switch to NTP should be explicit, alarmed and reflected in timestamp quality. It should not silently leave an application treating millisecond-grade time as microsecond-grade evidence.
NTP remains reasonable for office services, reporting and systems where millisecond precision is sufficient. A well-run local NTP service may keep hosts within hundreds of microseconds, but network congestion, virtualisation and poor source selection can worsen that.
Avoid treating a cloud host's displayed time as proof of its accuracy. The useful numbers are measured offset and uncertainty at the capture point, not the configured poll interval.
- Keep separate time-source and offset telemetry for each host, NIC and gateway.
- Alert on source loss, offset excursions, grandmaster changes and holdover duration, not only on a service being "up".
- Record leap-second handling, UTC representation and any conversion from TAI or venue-local time.
Set targets that operators can test
The figures below are typical market ranges, not universal service levels. A venue's published clock requirements, feed design and regulatory obligations take precedence. Set your own thresholds against the actual hardware and route, then verify them under load and during failover.
| Layer or timestamp | Typical measured accuracy range | Practical alert threshold | Evidence to retain |
|---|---|---|---|
| Host using local NTP | 100 microseconds to 1 millisecond | Offset above 1 millisecond, or source loss | Offset, peer, stratum and poll history |
| Host using software PTP | 5 to 50 microseconds | Offset above 100 microseconds | PTP state, source identity and offset |
| NIC hardware timestamp with PTP | 0.1 to 1 microsecond | Offset above 5 microseconds | NIC, driver, grandmaster and timestamp mode |
| External feed event time | 10 microseconds to 1 millisecond, feed dependent | Compare with feed specification and measured path | Raw event time, receive time and source metadata |
Thresholds should distinguish warning from action. A 5-microsecond alert may be useful for a hardware-timestamped market-data host, but it is noise on an NTP-managed reporting server.
Set a warning around half the action limit, alert on persistence as well as a single sample, and page only when the breach affects a critical path or evidence quality. Track percentiles and maximum excursions. A daily average can hide a short but material step.
Reconcile timestamps without erasing evidence
Do not overwrite a raw timestamp with a "corrected" one. Store the original value, clock identifier, capture point, sequence number and source-health state.
Where a downstream process needs a common timeline, calculate a derived timestamp using a versioned offset estimate. Retain the estimate's validity interval and uncertainty so analysts can tell whether two events are definitely ordered or merely appear ordered.
For each event, distinguish event time from receive time. A venue timestamp may describe when the matching engine processed an event; a gateway receive timestamp describes when a packet reached your network interface. The difference includes network and feed processing delay. It is not a direct measure of strategy reaction time. Compare like with like, and use sequence numbers to detect missing or reordered messages rather than inferring them from timestamps alone.
During reconciliation, build a timeline from the closest available capture points and quantify uncertainty. If host A is estimated to be 20 microseconds ahead of UTC with 5 microseconds of uncertainty, and host B is 10 microseconds behind with the same uncertainty, a 15-microsecond event gap is not solid evidence of ordering.
Preserve that ambiguity in reports. This matters in incident review, execution-quality analysis and dispute handling.
For duration measurements, use a monotonic counter on the same host. Across hosts, use synchronised hardware timestamps and include the observed offset and uncertainty.
Do not "fix" historical records with the current offset: clocks can step, drift or switch sources. Keep offset samples frequent enough to bracket the event window, typically every 1 to 10 seconds for critical hosts, with denser telemetry during failover tests.
Teams reviewing their wider platform controls can use the Trading Technology infrastructure archive as a reference point, but the reconciliation rules must reflect local capture points and venue specifications.
Run the checks as an operational routine
Clock synchronisation needs an owner across network, systems and trading operations. Put the checks into deployment and incident routines, not only the initial build. Test on production-equivalent hardware: virtualised test hosts can behave differently from NICs and switches in the live path.
- At deployment, verify PTP profile, domain, NIC timestamp mode, grandmaster identity and offset from the host that captures the packet.
- At least quarterly, test loss of the primary source, GNSS outage, grandmaster change, switch reboot and recovery from holdover. Confirm that alerts reach the right team.
- For each incident, retain raw packets or event records, offset telemetry, source changes, software versions and the reconciliation method used.
- After a time-service or network change, compare before-and-after offset distributions and check that application timestamps still mean the same thing.
Typical operating targets are only useful if they match the trading path. A firm may aim for sub-microsecond NIC alignment on an exchange-facing gateway while accepting 1 millisecond on a reporting service. Document why each target exists, who responds to a breach and what trading action follows. The mistake most readers will still make after reading this is treating a synchronised clock as proof that two timestamps are directly comparable.
Preguntas frecuentes
What is a good clock offset for a trading server?
It depends on the system and capture point. Typical hardware-timestamped PTP hosts can measure within 0.1 to 1 microsecond, while NTP-managed hosts may sit in the 100-microsecond to 1-millisecond range. Set limits against the actual path and its requirements.
Should a trading firm use PTP or NTP?
PTP with hardware timestamping is usually better for latency-sensitive market-data and order paths. NTP is often adequate for reporting and less time-critical services. Many firms use both, but should alarm on source changes and never assume their accuracy is interchangeable.
How often should trading servers check clock offset?
For critical hosts, offset telemetry every 1 to 10 seconds is a practical starting range, with closer monitoring during failover tests. Tune the rate to the clock service and telemetry load, and retain enough samples to cover an incident window.
How should a firm reconcile timestamps from different systems?
Preserve raw timestamps and identify each clock, capture point and source. Apply a versioned offset estimate only to derived records, and retain its validity period and uncertainty. Use monotonic clocks for same-host durations and sequence numbers to identify message gaps or reordering.
Can NTP timestamps support latency analysis?
They can support analysis where millisecond-scale precision is acceptable and measured offsets are known. For microsecond-level comparisons across systems, use a validated PTP setup and hardware timestamps. Do not infer precise latency from clocks whose offset and uncertainty are unknown.
