A nanosecond-scale algorithmic result can be genuine and still say almost nothing about end-to-end packet latency. Serious performance communication depends on identifying where the clock begins and ends.
1. Three different clocks
A logic-only decision interval isolates a constrained computational path. A kernel or userspace observation adds execution environment, scheduling and instrumentation effects. Wire-to-wire latency includes the complete ingress/egress and timestamp path. FPGA fabric timing is yet another boundary; pin-to-pin observations depend on clocking, I/O and physical capture.
None of these can be substituted for another. An in-program XDP decision is not a NIC-to-NIC result; a successful RTL simulation is not a calibrated physical FPGA result.
2. Report distributions and provenance
At minimum, a useful report identifies sample count, offered load, clock source, measurement location, p50/p99/p99.9 or stronger percentiles, maximum observations, dropped packets, environmental constraints, and exact candidate version. One unusually good sample does not justify a deterministic tail claim.
When a run fails, retain the failure. When multiple revisions exist, publish the identifier attached to the specific result rather than moving numbers to a newer implementation by association.
3. Why the host matters
Frequency policy, CPU affinity, interrupts, NUMA topology, NIC queues and measurement overhead change the observed path. The hardware boundary must include the actual timestamp mechanism and the possibility of clock skew. Read-only discovery of PTP Hardware Clock support is useful inventory; it does not prove that a paired TX/RX hardware timestamp sample has been obtained.
FPGA work similarly distinguishes an implementation that simulates, one that meets timing constraints, and one that has been directly measured on pins with a calibrated independent reference.
4. From laboratory demonstration to qualified statement
A defensible chain moves from algorithmic model through source-bound software tests, negative tests, environment-bound integration and, only when relevant, physical measurements. Evidence revisions need immutable references and scope-specific outcomes. A product buyer can then ask what is transferable to the buyer's infrastructure.
The current public demonstrators expose selected research behaviour and limitations. New OVH and FPGA findings will be reflected only when their configuration, timestamp or capture method, outcome and revision have been reconciled into a buyer-safe public record.
5. The decision rule
The right number is the one measured on the boundary that matters for the proposed transaction. Scope-qualified results create credibility; attractive but boundary-free numbers destroy it.
LATEST EVIDENCE / R22 · REVISION 1.1 · 09 NOV 2026
What changed after the physical NIC acquisition
The OVH NIC R22 owner-run evidence records 64/64 paired hardware RX/TX timestamps, a p50 of 136,837 ns, a p99 of 163,625 ns and successful original NIC configuration restoration. An earlier R21 attempt produced no valid pairs. The R22 interval is approximately 137–164 microseconds, not sub-microsecond performance.
The result is limited to the tested NIC RX-to-TX timing boundary, with 64 samples; it is not a complete two-host end-to-end guarantee or a result transferable to every private asset. The owner-held raw archive has not been independently re-read for this publication. The FPGA P3 campaign likewise reports a successful IDCODE and SHA-256 identity precheck, not a new calibrated pin-to-pin timing result.
The live public evidence register supersedes static summaries when a newer, owner-approved source-bound result is released.
Explore the supporting public context
These pages provide related demonstrators and evidence boundaries, not independent certification or a direct proof of every claim in this essay.
Independent research note. All reproduction-sensitive material and buyer-specific experimental protocols are withheld from public disclosure.