Pith. sign in

REVIEW 2 major objections 3 minor 16 references

An Experimental Evaluation of Accurate Scheduling and Hardware Timestamping on NVIDIA ConnectX NICs

T0 review · 2 major / 3 minor · reviewed 2026-08-02 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read New measurements show NVIDIA ConnectX-7 Accurate Scheduling puts 99% of frames within ±900 ns of the target time, with rare 5 μs outliers.

desk verdict Useful first measurement of ConnectX-7 timestamping and scheduling jitter, but the ±900 ns accuracy claim overreaches: only frame intervals were measured, not absolute time error. read the letter →

arxiv 2607.11305 v2 pith:7RKGMYFE submitted 2026-07-13 cs.NI

Takahiro Hirofuchi , Takaaki Fukai This is my paper · ORCID
classification cs.NI
keywords NVIDIAConnectX-7AccurateSchedulinghardwaretimestampingdeterministicEthernet5GfronthaulTime-SensitiveNetworkingPTPclockscheduledtransmission
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper measures the real timing accuracy of NVIDIA ConnectX-7 NICs' Accurate Scheduling and hardware timestamping, using an FPGA-based measurement platform with nanosecond resolution. It finds that receive and transmit hardware timestamps agree across independently clocked devices to about ±7–8 ns, but scheduled frame transmission is far less precise: roughly 99% of frames land within ±900 ns of the specified time, with occasional outliers up to about 5 μs. The authors conclude that Accurate Scheduling is good enough for 5G fronthaul, which tolerates tens of microseconds of delay, but not for nanosecond-level TSN traffic shaping. The numbers give network engineers a rare public reference point for deciding whether to rely on this hardware for deterministic Ethernet.

What carries the argument

The central machinery is Accurate Scheduling, a hardware mechanism that pauses a Send Queue until the NIC's PTP hardware clock reaches a designated time. The paper compares two modes: the older Clock Queue mode, which synchronizes a queue's execution to a pseudo Send Queue emitting periodic NOP completions at a configured interval (tx_pp), and the newer Send Queue mode, which encodes the target time directly in a WAIT WQE. Both rest on the same PHC that drives hardware timestamping. The accuracy of the schedule is judged with an FPGA-based capture platform that timestamps each frame's first bit at 6.4 ns resolution, providing an independent reference.

What would settle it

A direct absolute-time test: synchronize the measurement FPGA's clock or the host PTP to the NIC PHC, schedule frames with known absolute times, and record each frame's absolute receive timestamp against its spec. If the interval-based ±900 ns does not translate to absolute errors (e.g., a constant 5 μs offset appears), the paper's headline accuracy would need to be revised.

Watch

Extended reading notes

Core claim

On its own terms, the paper establishes that the NIC's PHC-driven timestamping is very stable (±7–8 ns across devices), while the hardware scheduling path introduces jitter about one hundred times larger. Approximately 99% of frames scheduled at 100 μs intervals arrive within ±900 ns of the target, and the remaining 1% can be off by up to 5 μs. The jitter is essentially the same whether the schedule is specified through the Clock Queue mode or the Send Queue mode, and it does not shrink when the Clock Queue's execution interval is lowered from 5 μs to 500 ns. This points to an internal NIC scheduling mechanism, not the software interface, as the source of the error.

Load-bearing premise

The scheduling-accuracy claim is based on the distribution of measured frame-to-frame intervals rather than on each frame's absolute time error, so it assumes the NIC's clock offset from real time is constant (or zero) across the experiment; any constant offset would be invisible in the interval statistics.

Editorial extensions

If this is right

  • 5G fronthaul deployments can rely on Accurate Scheduling to keep frame delivery within eCPRI's 25 μs one-way budget, since the observed 99% coverage is within ±900 ns and outliers stay under 5 μs.
  • TSN implementations requiring several-to-tens-of-nanoseconds transmission accuracy cannot use ConnectX-7 as-is; the paper explicitly says the accuracy is insufficient for TAS and ATS at 10GbE.
  • The similarity of results across scheduling modes and tx_pp values indicates that software-side configuration choices do not materially affect scheduling accuracy on ConnectX-7.
  • Hardware timestamping precision of ±7–8 ns is adequate for PTP-style synchronization and for debugging scheduled transmission, since it is an order of magnitude tighter than the scheduling jitter.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The interval-based analysis cancels any constant offset between the schedule clock and the measurement clock, so the true absolute scheduling error could be larger by a fixed amount; a follow-up experiment that synchronizes the measurement platform to the NIC's PHC would reveal that offset.
  • The 500 ns secondary peaks in the interval histograms suggest an internal scheduling quantum; a testable prediction is that varying the PHC frequency shifts this spacing, which would confirm a counter-based gate mechanism.
  • Because the paper used 100 μs intervals, it leaves open whether accuracy degrades at shorter intervals where frames queue back-to-back; the transmit-timestamp failure for back-to-back frames hints at such a limit.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

2 major / 3 minor

Summary. The paper experimentally characterizes the NVIDIA ConnectX-7 NIC's hardware timestamping and Accurate Scheduling transmission mechanism using an FPGA-based measurement platform (EFCC). It reports that receive and transmit hardware timestamps exhibit approximately ±7–8 ns variation, and that Accurate Scheduling transmits about 99% of frames within ±900 ns of the specified transmission time, with occasional outliers up to about 5 µs. Two scheduling modes, Clock Queue and Send Queue, are compared. The paper concludes that the mechanism is suitable for microsecond-level deterministic applications such as 5G fronthaul but not for nanosecond-level TSN.

Significance. If the reported claims are properly supported, this is a valuable public measurement for a commercial NIC feature that is otherwise poorly documented. The timestamping evaluation is careful: the platform is validated, clock drift is modeled, residual bounds are given, and the 2 ns timestamp resolution is inferred from a consistent LSB pattern. The finding that Clock Queue and Send Queue modes show no systematic accuracy difference is also informative. However, the headline scheduling claim conflates absolute transmission-time accuracy with frame-interval accuracy, and this must be corrected before the conclusions can be accepted as stated.

major comments (2)
  1. [Section IV, Tables III–IV, Figures 2–7] The abstract and Section IV claim that 'approximately 99% of frames are transmitted within ±900 ns of the specified transmission time,' but the experiment measures only frame-to-frame intervals as seen by EFCC. With scheduled times s_i = s_0 + iS and EFCC receive timestamps r_i = s_i + e_i + c, the reported interval is S + e_{i+1} − e_i. A constant offset c, and any common-mode absolute error e_i, cancel. Because the NIC PHC and EFCC clock are independent and unsynchronized, the first frame's absolute offset is never determined. The data therefore support '99% of inter-transmission intervals are within ±900 ns of 100 µs,' not the stronger claim about absolute scheduled transmission times. This needs either a synchronization experiment that establishes absolute time alignment, or a careful reframing of all claims and conclusions in terms of interval accuracy.
  2. [Section III.B, Tables I–II] The receive timestamp evaluation uses back-to-back frames and compares measured frame intervals with theoretical values. This establishes variation/precision of receive timestamps, not absolute accuracy: a constant offset in the receive timestamp is invisible. The summary and abstract phrase the result as 'receive and transmit hardware timestamps exhibit a measured variation of approximately ±7–8 ns.' This is acceptable only if 'variation' is interpreted as interval precision. The text should explicitly distinguish the receive result from the transmit result, where an independent EFCC reference is used.
minor comments (3)
  1. [Section IV, first paragraph] The text says the evaluation was performed 'by comparing the receive hardware timestamps recorded by EFCC with the scheduled transmission times,' but only interval statistics follow. This sentence should be revised to describe what is actually measured.
  2. [Tables III and IV] The column header 'tx_pp = 500 5,000' is ambiguous; use 'tx_pp = 500 ns' and 'tx_pp = 5,000 ns' explicitly.
  3. [Section III.C, Figure 1] The ±7–8 ns figure is derived from the isotonic regression residual range of 14.4 ns. Since this includes EFCC receive timestamp quantization (6.4 ns), it would be helpful to state explicitly how much of the residual is attributable to EFCC versus the NIC.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: results are direct measurements with an externally validated FPGA platform; self-citations are supporting tooling, and the main caveat is an evidentiary limitation, not circularity.

full rationale

The paper contains no derivation chain whose output is equivalent to its input. Scheduling and timestamping claims are experimental characterizations, not predictions from a fitted model. The EFCC platform is cited from the authors' prior work ([8], [9]), but its timing accuracy is independently validated in Section III-A: 50,000 back-to-back 1518-byte frames were all recorded at exactly 1235.2 ns intervals, and configured 6.4 us intervals appeared exactly, so the self-citation is not load-bearing. The ±7-8 ns transmit timestamping figure is the residual range after fitting linear/isotonic clock drift on the same dataset; this is a descriptive estimate of jitter, not a fitted parameter being renamed as a prediction. One evidentiary limitation should be flagged, but it is not circularity: Section IV states that timing accuracy was evaluated 'by comparing the receive hardware timestamps recorded by EFCC with the scheduled transmission times,' yet Tables III-IV and Figures 2-7 report only distributions of consecutive frame intervals. For a periodic schedule, a constant absolute offset between the NIC PHC and the EFCC clock cancels in interval differences, so the data directly support '99% of inter-transmission intervals within ±900 ns of 100 us' rather than the abstract's unqualified 'within ±900 ns of the specified transmission time.' This is a measurement-validity caveat about absolute time alignment, not a self-referential reduction; the measured behavior remains independent of the paper's own claims.

Assumptions & free parameters 1 free parameters · 4 assumptions · 0 invented entities

The central accuracy numbers rest on two assumptions: a fitted linear clock-drift model, and the equivalence of interval jitter to absolute scheduling error. Both are plausible but not independently evidenced. The measurement platform is self-built but validated. No new physical entities are introduced.

free parameters (1)
  • Clock-drift compensation slope/intercept (linear regression) = not reported
    Fitted to the transmit-timestamp residual analysis (Fig. 1) to remove relative oscillator drift; the reported ±7-8 ns accuracy is the residual range of this model, so the value depends on the fit.
assumptions (4)
  • domain assumption Relative oscillator frequency offset between ConnectX-7 and EFCC is constant during each experiment, so clock drift can be removed with a linear function.
    Invoked in Section III-C to convert raw timestamp differences into an accuracy estimate; if drift is non-linear, the residual estimate would be inflated or biased.
  • domain assumption The deviation of measured frame intervals from the 100-us target equals the deviation of each frame's transmission time from its specified absolute time.
    Used in Section IV to reinterpret interval histograms as scheduling accuracy; not verified because EFCC and NIC clocks are not synchronized.
  • domain assumption EFCC introduces no measurable timing variation, validated by back-to-back interval checks in Section III-A.
    Relied on as reference truth for both timestamp and scheduling evaluations.
  • standard math Standard 10GbE wire timing (64-byte frame = 70.4 ns, 1518-byte = 1235.2 ns).
    Used to compute theoretical frame intervals in Section III-B.

how reviews work

0 comments
Cite this review

Pith. "Pith review of An Experimental Evaluation of Accurate Scheduling and Hardware Timestamping on NVIDIA ConnectX NICs." pith.science (2026). https://pith.science/paper/7RKGMYFE

@misc{pith2026260711305,
  author       = {Pith},
  title        = {Pith review of: An Experimental Evaluation of Accurate Scheduling and Hardware Timestamping on NVIDIA ConnectX NICs},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/7RKGMYFE}},
  note         = {Machine review of arXiv:2607.11305}
}
abstract

High-precision packet transmission is becoming increasingly important in deterministic networking applications, including 5G fronthaul and Time-Sensitive Networking (TSN). Recent NVIDIA ConnectX network interface cards (NICs) provide Accurate Scheduling, a hardware-assisted mechanism for transmitting Ethernet frames at designated times, as part of their 5T for 5G feature set. They also provide hardware timestamping for received and transmitted frames. Although these functions are expected to satisfy the stringent timing requirements of 5G fronthaul, little public information is available regarding their timing accuracy and performance characteristics. This paper presents an experimental characterization of the Accurate Scheduling and hardware timestamping capabilities of the NVIDIA ConnectX-7 NIC. Using an FPGA-based measurement platform with deterministic frame generation and nanosecond-resolution timestamping, we first evaluate the precision of the receive and transmit hardware timestamps and then evaluate the transmission timing accuracy of Accurate Scheduling. The experimental results show that the receive and transmit hardware timestamps exhibit a measured variation of approximately $\pm$7-8 ns when compared across independently clocked Ethernet entities. Furthermore, Accurate Scheduling transmits approximately 99% of frames within $\pm$900 ns of the specified transmission time, while occasional outliers of up to approximately 5 us are observed. These results indicate that Accurate Scheduling is well suited for applications with latency requirements on the order of several tens of microseconds, such as 5G fronthaul, whereas its timing accuracy is insufficient for highly deterministic TSN applications, which typically require transmission timing accuracy on the order of several to several tens of nanoseconds.

Figures

Figures reproduced from arXiv: 2607.11305 by the authors.

Figure 1
Figure 1. Relative difference between the ConnectX-7 transmit hardware [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Distribution of actual frame intervals for 1518-byte frames in the [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 5
Figure 5. Actual frame intervals versus frame index for 1518-byte frames in [PITH_FULL_IMAGE:figures/full_fig_p006_5.png] view at source ↗

Review history (2 revisions) →

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

16 extracted references

  1. [1]

    Common Public Radio Interface: Requirements for the eCPRI Transport Network , Common Public Radio Interface, 2018

    2018

  2. [2]

    Common Public Radio Interface: eCPRI Interface Specification , Common Public Radio Interface, 2019

    2019

  3. [3]

    IEEE Instrumentation and Measurement Society , IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems, Institute of Electrical and Electronics Engineers, 2019

    2019

  4. [4]

    IEC/IEEE Draft International Standard Time-Sensitive Networking Profile for Industrial Automation, Institute of Electrical and Electronics Engineers, 2023

    2023

  5. [5]

    IEEE Standard for Local and metropolitan area networks - Time-Sensitive Networking Profile for Automotive In-Vehicle Ethernet Communications, Institute of Electrical and Electronics Engineers, 2025

    2025

  6. [6]

    Draft Standard for Local and Metropolitan Area Networks: Time-Sensitive Networking for Aerospace Onboard Ethernet Communications, Institute of Electrical and Electronics Engineers, 2025

    2025

  7. [7]

    IEEE Standard for Local and Metropolitan Area Networks--Bridges and Bridged Networks , Institute of Electrical and Electronics Engineers, 2022

    2022

  8. [8]

    The AIST-TSN project repository, https://github.com/CCIRT/aist-tsn/ , 2024-2026

    2024

Show all 16 references
  1. [9]

    A. B. Ahmed, T. Hirofuchi, and T. Fukai, ``Efcc: Ethernet frame crafter and capture for tsn research,'' in Proceedings of the 50th IEEE Conference on Local Computer Networks (LCN). 1em plus 0.5em minus 0.4em IEEE, 2025, pp. 1--9

    2025

  2. [10]

    Multi-access Edge Computing (MEC); Framework and Reference Architecture, European Telecommunications Standards Institute, Jun 2025

    2025

  3. [11]

    Multi-access Edge Computing (MEC); Use Cases and Requirements, European Telecommunications Standards Institute, Jun 2025

    2025

  4. [12]

    Intel Cooperation , Intel Ethernet Controller I210 Datasheet, Revision Number: 3.7, 2021

    2021

  5. [13]

    M. Bosk, F. Rezabek, K. Holzinger, A. G. Marino, A. A. Kane, F. Fons, J. Ott, and G. Carle, ``Methodology and infrastructure for tsn-based reproducible network experiments,'' IEEE Access, vol. 10, pp. 109\,203--109\,239, 2022

    2022

  6. [14]

    Y. Oge, Y. Kobayashi, T. Yamaura, and T. Maegawa, ``Software-based time-aware shaper for time-sensitive networks,'' IEICE Transactions on Communications, vol. E103.B, no. 3, pp. 167--180, 2020

    2020

  7. [15]

    C. Xue, T. Zhang, and S. Han, ``Towards cost-effective real-time high-throughput end station design for time-sensitive networking (tsn),'' in Proceedings of the 61st ACM/IEEE Design Automation Conference, ser. DAC '24. 1em plus 0.5em minus 0.4em Association for Computing Machi...

    2024

  8. [16]

    Hirofuchi, A

    T. Hirofuchi, A. B. Ahmed, and T. Fukai, ``Implementation and evaluation of a time-sensitive networking endpoint for asynchronous traffic shaping,'' IEEE Access, vol. 14, pp. 21\,119--21\,136, 2026

    2026

Pith tools

Reviewed August 2, 2026 · model on record in the stance chip above.