---
title: "Hardware Packet Timestamps Do Not Automatically Synchronize Two Servers"
description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20."
canonical: "https://www.leviathansystems.co/articles/network-hardware-timestamp-versus-clock-synchronization"
last-updated: "2026-10-20"
---

# Hardware Packet Timestamps Do Not Automatically Synchronize Two Servers

Leviathan Systems — Technical content
Published 2026-10-20; updated 2026-10-20.

Hardware timestamping records when a packet reaches a supported hardware capture point. Clock synchronization establishes a relationship between clocks. To interpret a timestamp difference between servers, establish the two event boundaries, the clocks supplying their values and the uncertainty in their relationship. A NIC feature or a value expressed in nanoseconds cannot supply all three answers.

## Locate the event before interpreting its time

A packet timestamp describes an event at a particular observation point. Decide whether that point matches the beginning or end of the interval being claimed.

The Linux kernel documentation places hardware receive and transmit timestamp generation at the adapter. Software receive timestamps follow the driver's handoff to the kernel receive stack; software transmit timestamps precede the driver's handoff to the interface. These are capture locations, not a universal adapter accuracy specification.

An adapter-to-adapter interval excludes processing outside those boundaries. An application-to-application interval can cover a different portion of the same communication. Changing capture points can therefore change the reported interval without changing the communication itself. A smaller number can mean a narrower measurement.

References: [K1](https://docs.kernel.org/networking/timestamping.html)

## Identify the clock that supplies each number

Capture location and clock identity answer different questions. An adapter event still needs a clock value, and that clock must be related to the other timestamp's clock.

NVIDIA's Holoscan SDK 4.1.0 Data Flow Tracking documentation, updated May 11, 2026, requires synchronized clocks for its distributed application flow tracking. Its hardware-timestamping discussion treats the NIC physical clock and Linux system clock, CLOCK_REALTIME, separately. This named application context supplies no universal AI timing requirement.

With two servers, distinguish each NIC's PTP (Precision Time Protocol) hardware clock, or PHC, from each host's system clock. Agreement between the NIC clocks does not establish agreement between the system clocks. System-clock evidence likewise does not establish the relationship between raw NIC timestamps. Follow the clock supplying each value; sharing a host does not make two clock identities interchangeable.

References: [H1](https://docs.nvidia.com/holoscan/archive/4.1.0/flow_tracking.html)

## Distinguish wall-clock labels from elapsed time

Two readings from the same host still need the right clock semantics. A UTC-style label alone does not establish an uninterrupted elapsed-time measure. Linux man-pages documents that CLOCK_REALTIME can jump and undergo frequency adjustments. CLOCK_MONOTONIC avoids discontinuous system-time jumps but remains subject to frequency adjustments; consecutive readings cannot go backwards, yet may be equal. Linux CLOCK_MONOTONIC excludes suspended time, while CLOCK_BOOTTIME includes it. These properties determine what a subtraction can mean; none establishes perfect accuracy.

Fictional example CL01 holds the observation boundaries fixed on one host for exactly 10 ms of awake elapsed time, with no suspension. Stipulate matching clock rates apart from one negative 20 ms wall-clock step between the readings, exact capture and no other error. The wall-clock subtraction is 10 ms minus 20 ms, giving -10 ms. A suitable monotonic pair, stipulated to advance with that awake interval, advances 10 ms. The negative result describes the invented clock discontinuity, not an event finishing before it began. These are teaching assumptions, not an observed report or a clock-adjustment instruction.

A suitable local interval does not establish a shared timeline across hosts. Linux CLOCK_MONOTONIC values have a boot-related origin; two servers need an established clock relationship before their readings can support a cross-host subtraction. Nor can a monotonic interval silently replace raw NIC timestamps: that would change the source clocks whose relationship needs evidence.

The related CUDA timing article addresses another question: whether the selected start and finish cover submission return, completed device work or useful-output availability. Identifying those events and understanding the supplying clock are both necessary. A suitable clock cannot make a narrower observation cover omitted work.

References: [C1](https://man7.org/linux/man-pages/man2/clock_gettime.2.html)

## Nanosecond representation is not nanosecond agreement

A number expressed in nanoseconds describes its representation. Printing additional digits does not demonstrate that the underlying event was located that accurately, that the clock advances in equally fine physical increments, or that a second clock gives a sufficiently close value for the same event.

NIST's introductory IEEE 1588 terminology describes synchronized clocks using a shared epoch and a specified uncertainty. The epoch supplies the origin for the time labels; the uncertainty bounds their agreement. Those concepts give the buyer a more useful question than how many digits a display contains: what relationship between these particular clocks is supported, and with what uncertainty?

This also separates relative agreement from agreement with an external reference. Two clocks could agree closely with each other while both being offset from that reference. The intended measurement determines which relationship matters. Matching units alone establishes neither relationship.

References: [N1](https://www.nist.gov/el/intelligent-systems-division-73500/meanings-common-terms-used-ieee-1588)

## Why 40 microseconds can appear as 140 microseconds

Fictional example TIME-01 uses two fixed packet capture boundaries. Stipulate that the true elapsed time between them is exactly 40 microseconds, or 40,000 nanoseconds. The sending clock agrees with an invented common reference. The receiving clock is exactly 100 microseconds, or 100,000 nanoseconds, ahead of that reference throughout the interval. Assume equal clock rates during this interval, exact event capture and no other error. These are invented assumptions, not measured clock or network behavior.

At the sending event, let the reference and sending timestamp both read 1,000,000,000 nanoseconds. At the receiving event, the reference reads 1,000,040,000 nanoseconds. Because the receiving clock is ahead, its reported timestamp reads 1,000,140,000 nanoseconds.

Subtracting the reported sending timestamp from the reported receiving timestamp gives 140,000 nanoseconds, or 140 microseconds. That result contains the stipulated 40-microsecond interval plus the positive 100-microsecond relative clock offset. Both timestamps are expressed in nanoseconds; that representation has not removed the offset.

Within this deliberately exact model, accounting for the known 100-microsecond offset recovers the 40-microsecond interval. A real claim would need evidence for the applicable clock relationship and its uncertainty. The invented offset is not an acceptable error budget, an observed synchronization result or a value to apply to another system.

The example also holds its capture points fixed. Moving either boundary changes the interval being described. Correcting a clock offset cannot turn an adapter-to-adapter interval into an application-to-application interval.

## Evaluate the timing relationship beyond the NIC feature

A hardware-timestamping capability can be relevant to a timing system without completing that system. RFC 9760, published in May 2025, identifies the grandmaster as the reference time source for a PTP domain and describes profiles as constraints on PTP options and features. A capture location, a source of time and the rules governing a timing arrangement are different properties.

For a proposed PTP arrangement, have the appointed timing team explain the selected time source, applicable profile, communication path and receiving clocks. The proposal must also explain how the application obtains time from, or relates its time to, the relevant clock. The buyer needs the complete relationship that supports the intended comparison, rather than a list of devices bearing a timing feature label. The RFC's enterprise profile is a concrete example of the profile concept, not a recommendation for the proposed network.

The supplied evidence should concern that relationship under the intended use and identify its uncertainty over the period being assessed. TIME-01 assumed a constant offset and equal rates for one interval. If the relationship changes, a correction established for one interval cannot simply be presumed valid for another. Neither a NIC capability statement nor an isolated clock comparison supplies a universal timing guarantee.

References: [R1](https://www.rfc-editor.org/rfc/rfc9760.html)

## Make the feature answer the purchase requirement

If the requirement is to timestamp a particular adapter event, the relevant questions concern support for that event in the offered hardware and software, and the clock used for the resulting value. A statement about a different event or clock leaves that requirement unresolved.

If the requirement is to interpret one-way elapsed time between servers, add the relationship between the two clocks and its uncertainty. If the application instead compares host system timestamps, evidence limited to the NIC clocks leaves an additional relationship to establish. These are consequences of the measurement mechanism, even when the proposed adapters are identical.

If the sales claim is faster distributed processing, ask for evidence concerning that workload separately. Establishing a clock relationship can make an elapsed-time comparison interpretable; it does not, by itself, shorten the communication interval or accelerate every AI job. Low network latency and synchronized clocks are different claims.

Compare offers against the same event boundaries, clock identities and intended use before allowing a precision-timing label to decide the NIC purchase. The clock relationship need not be perfect, but its demonstrated uncertainty must be suitable for the actual decision. That suitability remains with the responsible application and timing owners.

## Connect a physical question to the appropriate service

If the timing review identifies a separate physical connection or identification question, Leviathan's Physical-Layer Testing & Installation Verification service is a starting point for discussing agreed visual, cable-ID, labeling and physical-connectivity checks and their handoff records. Use the service and project-inquiry links below with a nonconfidential outline of the affected connections and the physical question to resolve.

Timing architecture, PTP profile selection, clock configuration and synchronization validation require their separately appointed specialists. Any instrument work also requires its actual method, equipment, personnel and criteria to be confirmed. This article explains a purchasing decision; it supplies no installation or operating procedure or approval for actual work.

## Primary sources

- [K1 — Linux kernel documentation: Timestamping, Timestamp Generation](https://docs.kernel.org/networking/timestamping.html). Checked 2026-10-20. Current unversioned documentation distinguishes adapter, kernel and driver capture locations. These locations help define the interval being claimed; they supply no universal device accuracy.
- [H1 — NVIDIA Holoscan SDK 4.1.0: Data Flow Tracking](https://docs.nvidia.com/holoscan/archive/4.1.0/flow_tracking.html). Checked 2026-10-20. Archived SDK 4.1.0 documentation, updated May 11, 2026. Used for its distributed-flow clock-synchronization requirement and the distinction between the NIC physical clock and CLOCK_REALTIME.
- [N1 — NIST: Meanings of common terms used in IEEE 1588](https://www.nist.gov/el/intelligent-systems-division-73500/meanings-common-terms-used-ieee-1588). Checked 2026-10-20. Introductory terminology created October 27, 2010 and updated May 29, 2026. Used for epoch and synchronization uncertainty, rather than current edition-specific protocol requirements.
- [R1 — IETF RFC 9760: Enterprise Profile for the Precision Time Protocol with Mixed Multicast and Unicast Messages](https://www.rfc-editor.org/rfc/rfc9760.html). Checked 2026-10-20. May 2025 RFC, introduction and technical terms. Used for the grandmaster and profile concepts; its enterprise profile is not selected as a design for another network.
- [C1 — Linux man-pages: clock_gettime(2), clock definitions](https://man7.org/linux/man-pages/man2/clock_gettime.2.html). Checked 2026-10-20. Linux CLOCK_REALTIME, CLOCK_MONOTONIC and CLOCK_BOOTTIME definitions distinguish jumps, frequency adjustment and suspension accounting; these properties supply neither an accuracy guarantee nor cross-host synchronization.

## Related Leviathan resources

- [Physical-Layer Testing & Installation Verification](/services/network-testing)
- [Project inquiry: define the physical connection question](/contact?service=network-testing&from=%2Farticles%2Fnetwork-hardware-timestamp-versus-clock-synchronization)
- [CUDA timing: submission, completed events and caller endpoints](/articles/cuda-events-versus-host-submission-timing)
- [FEC counts, packet errors and physical evidence](/articles/gpu-ethernet-fec-counters-vs-fiber-test-reports)
- [GPU-to-NIC PCIe topology and GPUDirect RDMA](/articles/gpu-server-pcie-topology-gpudirect-rdma)
- [Local fabrics and the inter-site network handoff](/articles/multi-site-ai-cluster-network-handoff)

## Discuss the physical connection question

Share the affected connection identities, available physical records and the checks or documentation you need. Our team will follow up to discuss scope, requirements and availability.

[Discuss the scope](/contact?service=network-testing&from=/articles/network-hardware-timestamp-versus-clock-synchronization)