Pith. sign in

REVIEW 3 major objections 6 minor 16 references

Characterization of latency and jitter in TSN emulation

T0 review · 3 major / 6 minor · reviewed 2026-08-07 · deepseek-v4-flash

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

Pith's one-line read The paper establishes that a Linux/Mininet TSN emulation can be profiled with four timestamping methods, and that the measured bridge latency and intrinsic jitter suffice to compute and deploy a correct time-aware schedule for a…

desk verdict Useful TSN-in-Mininet engineering, but the schedule validation can't tell a correct GCL from an all-open gate. read the letter →

arxiv 2506.02133 v1 pith:IBKNY6IA submitted 2025-06-02 cs.NI

Álex Gracia , José Luis Briz , Héctor Blanco-Alcaine , Juan Segarra , Alitzel G. Torres-Macías , Antonio Ramírez-Treviño This is my paper · ORCID
classification cs.NI
keywords TSNIEEE802.1QbvTime-AwareShaperMininettimestampingjitterlatencycharacterizationtaprio
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

The paper tries to show that a software-only TSN emulation on a single Linux host is usable for designing time-sensitive schedules, not just for functional prototyping. It compares four timestamping methods, measures bridge latency and intrinsic jitter across three platform configurations, and feeds those measured parameters into an IEEE 802.1Qbv gate-scheduling solver. The proof of concept is a three-stream use case deployed with taprio, whose measured end-to-end latencies stay an order of magnitude below the 10–30 ms deadlines, with gate windows sized so frames pass through. If the claim holds, network designers can iterate on TSN schedules in software before committing to a physical testbed, and the same timestamping recipe can be reused in containerized and tunneled networks.

What carries the argument

The load-bearing mechanism is the timestamping chain built on Linux networking primitives: taprio qdisc emulates the Time-Aware Shaper's queue gates; clsact qdisc copies each frame's VLAN PCP field into the skbuff priority so taprio classifies correctly; veth pairs act as NICs; and a netem qdisc nested under taprio emulates transmission time. Timestamping is read at five points (T1–T5) using three methods: clock_gettime for send and receive end-host times, plus AF_PACKET sockets and XDP BPF helpers at bridge ingress. The solver takes per-stream period and deadline together with four network parameters (transmission time, propagation time, bridge latency, intrinsic jitter) to produce gate-control-list entries; the paper estimates intrinsic jitter at 500 µs and uses the resulting schedule to configure taprio.

What would settle it

Rerun the three-stream use case with deadlines tightened toward the measured microsecond latencies (for example, 1–2 ms) and count frames that miss or are delayed by the taprio gates; if the 500 µs intrinsic-jitter estimate is too small, some frames will miss their window even though the schedule is feasible, while a clean pass at those tighter bounds would confirm the estimate.

Watch

Extended reading notes

Core claim

The central claim is that a single Linux machine running Mininet, with the taprio qdisc emulating the IEEE 802.1Qbv Time-Aware Shaper, veth pairs as links, and timestamping hooks placed in user space, AF_PACKET, and XDP, can reproduce a TSN network closely enough to design, deploy, and verify a gate schedule. It reports that bridge latency and end-to-end latency measured with AF_PACKET (M2.2) and with XDP (M3) agree to within a few microseconds; that the RT-optimized and Intel-TCC configurations (C2 and C3) reduce latencies and intrinsic jitter relative to the plain preemptible kernel (C1); and that for a three-stream use case, all end-to-end latencies came out on the order of microseconds, an order of magnitude below the 10–30 ms deadlines, with the TAS gates wide enough for every frame.

Load-bearing premise

The result leans on the informal 500 µs intrinsic-jitter estimate used to size the TAS gate windows, and the reported test cannot detect whether that estimate is too small because all measured latencies remain far below the stream deadlines.

Editorial extensions

If this is right

  • For TSN emulation in Mininet, AF_PACKET timestamping is a practical substitute for XDP: differences in end-to-end latency are a few microseconds, and AF_PACKET is far easier to implement.
  • Fully preemptible kernels and Intel TCC cut both latency and intrinsic jitter, but on a few-core industrial PC the process-to-core allocation matters as much as the kernel configuration.
  • A correct 802.1Qbv schedule can be synthesized from measured emulated parameters and deployed unchanged into taprio qdiscs, so the emulated platform can be used to iterate on schedules before touching hardware.
  • Transmission time can be emulated with a netem qdisc nested under taprio, at the cost of dropping the first frame per queue, which is handled by a dry run; propagation time still requires kernel changes.

Reading between the lines

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

  • If the timestamping methodology transfers as claimed, the same profiling setup could be used for containerized or tunneled networks where physical timestamping is unavailable.
  • The 500 µs jitter estimate is the loosest link; a systematic sensitivity study varying background load and core allocation would show how much the gate window sizes can be shrunk before frames are missed.
  • The use-case validation is a sanity check rather than a stress test because 10–30 ms deadlines dwarf the observed microsecond latencies; repeating it with deadlines near the measured latency would test the schedule synthesis rather than just the emulation.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 6 minor

Summary. The manuscript presents a practical methodology for profiling traffic in a Mininet-based TSN emulation environment. It defines four timestamping variants (M1 via clock_gettime, M2 via AF_INET/AF_PACKET sk_buff timestamps, M3 via XDP/BPF), compares them at bridge and end-station measurement points, and characterizes bridge latency and end-to-end jitter on three platform configurations: a stock kernel (C1), a PREEMPT_RT kernel (C2), and an Intel TCC system (C3). It then solves an IEEE 802.1Qbv TAS schedule for a three-stream use case using measured latencies and a 500 us intrinsic-jitter estimate, deploys the schedule through taprio, and reports microsecond-scale e2e.nic latencies well below the 10-30 ms deadlines. The paper claims that this validates both the timestamping methodology and the correctness of the deployed schedule.

Significance. If the validation were conclusive, this would be a useful engineering contribution: it resolves several undocumented Linux/Mininet TSN integration issues (veth queue limitations, clsact/taprio interplay, VLAN/PCP mapping), offers a reproducible timestamping comparison, and shows how measured platform parameters can feed a scheduling solver. The absence of circularity is a strength: the measured bridge latency and jitter are inputs to the ILP solver rather than fitted to make the schedule work. However, the current evidence does not yet establish the central schedule-correctness claim, because the use case cannot distinguish a correctly sized TAS schedule from an all-open or over-provisioned gate configuration. The 500 us jitter estimate is also insufficiently supported. These are fixable with additional experiments and reporting, rather than fundamental flaws.

major comments (3)
  1. [IX-C, Figs. 11 and 12] The use-case experiment does not provide a discriminating test of the central claim that a correct TAS schedule was computed and deployed. The three streams have periods equal to their deadlines (10, 20, 30 ms), and the measured e2e.nic latencies are in the microsecond range, about three orders of magnitude below the deadlines. With only three streams and no competing traffic, an all-open taprio configuration, a schedule with much wider gate windows, or even a schedule with incorrect gate offsets would produce the same observations: no queueing delay, microsecond latencies, and all frames passing through. The absence of any baseline (taprio disabled, a deliberately wrong GCL, or worst-case arrivals at gate boundaries) means that Figs. 11 and 12 cannot falsify an incorrect schedule. Please add such a baseline, or report a quantitative comparison between measured gate pass-through times and the computed gate close times showing that an incorrectly sized window would have been detected.
  2. [IX-A, intrinsic jitter estimate (500 us)] The value of 500 us used to size the TAS gate windows is not derived rigorously. Section IX-A obtains it from three informally stated figures: bridge jitter 'about 200 us' (Fig. 6), e2e.nic jitter 'around 10 us', and a talker delay of about 80 ns. It is unclear what statistic is being called jitter (max-min, IQR, 99th percentile), and the relation between a 200 us bridge-jitter term and a 10 us e2e.nic jitter term is not explained. Because the gate windows are only as safe as this free parameter, the paper should define the jitter metric, report its empirical distribution, and include a sensitivity analysis (e.g., recomputing and deploying gates with smaller and larger margins) or a direct measurement of the maximum observed deviation from the scheduled gate intervals.
  3. [IX-A, netem first-frame loss] The paper states that instantiating a netem qdisc as a child of taprio causes the first frame entering each queue to be lost, and that the workaround is only a dry run before profiling. This is a correctness issue for a TSN setting: if the netem emulation of transmission time drops frames at queue initialization, the reported validation may be excluding exactly the frames that stress the schedule. Please quantify the number of lost frames during the experiment, state whether they are excluded from the latency statistics, and justify the workaround by showing that the loss occurs only once per queue and never during steady-state operation.
minor comments (6)
  1. [VIII-B] The sentence comparing M2.2 and M3 mislabels M3 as AF_PACKET; M3 is the XDP/BPF method. Please correct the labeling in the text and in the caption of Fig. 6.
  2. [IX-B] The text says the script 'configures the CGLs in the taprio qdiscs'; this should be 'GCLs' (Gate Control Lists).
  3. [VIII-A, Table II] Please clarify whether the AF_PACKET (M2.2) timestamp at T2/T3 is taken from the cloned sk_buff before or after veth_xmit, and how the cloning overhead is accounted for in the bridge-latency comparison.
  4. [Fig. 12] The axes, units, and plotted quantity in Fig. 12 are not defined in the text; specify whether the figure shows observed pass-through times, scheduled gate intervals, or both, and what comparison supports the 'wide enough' conclusion.
  5. [Section VII] Please state whether the 1000 random frames used for characterization come from a single run or multiple runs, and whether the box plots pool all frames; otherwise the reported IQR and outlier behavior are hard to interpret.
  6. [References] References [13] and [15] lack complete publication details, and [16] should be updated with volume and page numbers rather than 'pp. 1-1'.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: measured parameters are inputs to an external solver and schedule correctness is checked by independent latency and gate observations.

full rationale

The paper's derivation chain is linear: (1) timestamping methods are compared and bridge latency/jitter are measured (Sec. VIII); (2) the measured values, stream periods, and deadlines are fed to the ILP-based TAS scheduler [16] (Sec. IX-A); (3) the resulting GCL is deployed via taprio (Sec. IX-B); (4) correctness is checked by observing e2e.nic latencies and gate pass-through (Sec. IX-C). None of these steps equates the output to an input by construction. The self-citation [16] is a tool citation: the solver is not invoked as a uniqueness theorem or as a substitute for validation, and its output is not assumed equal to the measured latencies. The 500 µs intrinsic-jitter estimate in Sec. IX-A is an informal combination of component measurements (talker delay 80 ns, bridge jitter ~200 µs, e2e.nic jitter ~10 µs); it is chosen before scheduling and is not fitted to make the schedule pass, so the deployed schedule is not a statistically forced prediction. Two weaknesses are real but not circular: the Sec. IX-C validation is under-powered (observed latencies are in the microsecond range against 10–30 ms deadlines, and no deliberately wrong GCL baseline is reported), and the 500 µs estimate is not rigorously derived. These are correctness risks, not instances of prediction-by-construction. No equation in the paper reduces a claimed result to its own input, and no load-bearing premise rests on an unverified self-citation. Therefore no significant circularity.

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

The central claim depends on the fidelity of Linux emulation components (veth, taprio, netem) and on the correctness of a hand-estimated jitter value. No new theoretical entities are introduced. The free parameters are practical estimates and configurations rather than fitted model coefficients.

free parameters (2)
  • Intrinsic jitter estimate = 500 µs
    Used as a safety margin for TAS scheduling; estimated from measured bridge jitter (~200 µs), e2e jitter (~10 µs), and talker delay (80 ns) without a formal derivation.
  • netem transmission time value = not specified
    The paper uses a netem qdisc to emulate transmission time but does not report the configured rate or delay, so the exact scheduling input is unknown.
assumptions (4)
  • domain assumption veth driver behavior approximates real NIC timing for TSN purposes
    The paper builds on veth to emulate the data-link layer and assumes its timing (latency, jitter) is representative for profiling.
  • domain assumption Zero clock skew in Mininet obviates IEEE 802.1AS emulation
    Section IV states all processes share one clock, so no time synchronization is needed; this assumes no other clock-related jitter is introduced.
  • domain assumption taprio qdisc correctly emulates IEEE 802.1Qbv TAS
    The paper uses taprio as the TAS and assumes its gate behavior matches the standard closely enough for schedule validation.
  • domain assumption First-frame loss in netem is benign and fully mitigated by a dry run
    Section IX-A acknowledges the first frame is lost and a dry run is performed, assuming this does not affect the validity of subsequent measurements.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Characterization of latency and jitter in TSN emulation." pith.science (2026). https://pith.science/paper/IBKNY6IA

@misc{pith2026250602133,
  author       = {Pith},
  title        = {Pith review of: Characterization of latency and jitter in TSN emulation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/IBKNY6IA}},
  note         = {Machine review of arXiv:2506.02133}
}
read the original abstract

This research focuses on timestamping methods for profiling network traffic in software-based environments. Accurate timestamping is crucial for evaluating network performance, particularly in Time-Sensitive Networking (TSN). We explore and compare four timestamping techniques within a TSN emulation context, though its findings extend to other network scenarios. The study leverages the Mininet emulator to model TSN networks, defining hosts, bridges, links, and traffic streams. It characterizes bridge latencies and jitter, solves the TSN scheduling problem based on measured parameters, and evaluates the correctness of a deployed schedule for a use case. Key contributions include a methodology for software-based timestamping, solutions for TSN emulation challenges in Linux and Mininet, and experimental insights for optimizing TSN emulation platforms on various system configurations, with and without Intel TCC, either on a high-end workstation or on an industrial PC.

Figures

Figures reproduced from arXiv: 2506.02133 by the authors.

Figure 1
Figure 1. Overview of the experimental setup for TSN emulation [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 3
Figure 3. Structure of the IEEE 802.1Qbv Time-Aware Shaper [PITH_FULL_IMAGE:figures/full_fig_p002_3.png] view at source ↗
Figure 4
Figure 4. Linux qdiscs for TSN emulation on Mininet. [PITH_FULL_IMAGE:figures/full_fig_p003_4.png] view at source ↗
Figures from the paper (7 more)
Figure 5
Figure 5. Figure 5: Timestamping points at end-stations and bridges, and [PITH_FULL_IMAGE:figures/full_fig_p004_5.png]
Figure 6
Figure 6. Figure 6: Bridge latency (br1L) measured with M2.2 and M3. [PITH_FULL_IMAGE:figures/full_fig_p005_6.png]
Figure 7
Figure 7. Figure 7: End-to-end latency e2e.nic measured with M2.2 and M3. liers ( [PITH_FULL_IMAGE:figures/full_fig_p005_7.png]
Figure 8
Figure 8. Figure 8: Impact of using configurations C1, C2, or C3 (Tab. I) in latency calculations, using XDP (M3) at [PITH_FULL_IMAGE:figures/full_fig_p006_8.png]
Figure 9
Figure 9. Figure 9: Impact of process allocation in latency calculations (C3, M2.2 at [PITH_FULL_IMAGE:figures/full_fig_p006_9.png]
Figure 10
Figure 10. Figure 10: Use case network configuration. C. Experimental results [PITH_FULL_IMAGE:figures/full_fig_p006_10.png]
Figure 12
Figure 12. Figure 12: Pass-through times at the TAS gates of bridge B1. [PITH_FULL_IMAGE:figures/full_fig_p007_12.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

16 extracted references · 16 canonical work pages

  1. [3]

    Evaluation of Online Schedule Synthe- sis Algorithms for Time-Based Scheduled Time Sensi- tive Networks,

    A.O. Mildner, “Evaluation of Online Schedule Synthe- sis Algorithms for Time-Based Scheduled Time Sensi- tive Networks,” M.S. thesis, Department of Informatics, City, State, 2019, MSc Thesis. Supervisor: Prof. Dr.-Ing. Georg Carle. Advisors: Max Helm, Benedikt Jaeger, Dr. Marcel Wagner (Intel), H´ ector Blanco Alcaine (Intel)

    work page 2019

  2. [6]

    Failure Handling for Time-Sensitive Net- works using SDN and Source Routing,

    G.N. Kumar, K. Katsalis, P. Papadimitriou, P. Pop, and G. Carle, “Failure Handling for Time-Sensitive Net- works using SDN and Source Routing,” in Proceedings of 2021 IEEE 7th International Conference on Network Softwarization, United States, 2021, pp. 226–234, IEEE, 7th International Conference on Network Softwarization, NetSoft 2021 ; Conference date: 2...

    work page 2021

  3. [16]

    Fast IEEE802.1Qbv Gate Scheduling through Integer Linear Programming,

    A.G. Torres-Mac ´ ıas, J. Segarra, J.L. Briz, A. Ram ´ ırez- Trevi˜ no, and H. Blanco-Alcaine, “Fast IEEE802.1Qbv Gate Scheduling through Integer Linear Programming,” IEEE Access, pp. 1–1, 2024, https://doi.org/10.1109/ ACCESS.2024.3440828

    work page arXiv 2024

  4. [1]

    IEEE Standard for Local and Metropolitan Area Networks–Bridges and Bridged Networks, IEEE Stan- dard 802.1Q-2014,

    IEEE, “IEEE Standard for Local and Metropolitan Area Networks–Bridges and Bridged Networks, IEEE Stan- dard 802.1Q-2014,” 2014

    work page 2014

  5. [2]

    Mininet,

    “Mininet,” https://mininet.org/

    work page

  6. [4]

    A Model-Based Approach to Auto- matic Generation of TSN Network Simulations,

    M. Samson, T. Vergnaud, E. Dujardin, L. Ciarletta, and Y.Q. Song, “A Model-Based Approach to Auto- matic Generation of TSN Network Simulations,” 2022 IEEE 18th International Conference on Factory Com- munication Systems (WFCS), pp. 1–8, 2022, https: //ieeexplore.ieee.org/document/9779173

    work page arXiv 2022

  7. [5]

    Emulation vs. Reality: Hardware/Software Co-Design in Emulated and Real Time-sensitive Networks,

    M. Ulbricht, J. Acevedo, S. Krdoyan, and F.H.P. Fitzek, “Emulation vs. Reality: Hardware/Software Co-Design in Emulated and Real Time-sensitive Networks,” Eu- ropean Wireless 2021; 26th European Wireless Confer- ence, pp. 1–7, 2021, https://ieeexplore.ieee.org/ document/9657100

    work page arXiv 2021

  8. [7]

    The TSN Building Blocks in Linux

    Ferenc Fejes, P´ eter Antal, and M´ arton Kerekes, “The tsn building blocks in linux,” 2022, https://arxiv.org/ abs/2211.14138

    work page Pith review arXiv 2022

Show all 16 references
  1. [8]

    The eXpress data path: fast programmable packet processing in the operating system kernel,

    T. Høiland-Jørgensen, J.D. Brouer, D. Borkmann, J. Fastabend, T. Herbert, D. Ahern, and D. Miller, “The eXpress data path: fast programmable packet processing in the operating system kernel,” in CoNEXT ’18, New York, NY, USA, 2018, p. 54–66, Association for Com- puting Machine...

    2018 doi

  2. [9]

    Af packet linux reference manual,

    “Af packet linux reference manual,” https://man7.org/ linux/man-pages/man7/packet.7.html

  3. [10]

    On getting tc classifier fully pro- grammable with cls bpf.,

    D. Borkmann, “On getting tc classifier fully pro- grammable with cls bpf.,” in netdev 1.1, Feb 10-12, Seville, Spain , 2016, https://api.semanticscholar. org/CorpusID:198117287

    2016

  4. [11]

    Linux Socket Filtering aka Berkeley Packet Filter (BPF) Linux Kernel Doc- umentation,

    Starovoitov, A. et al., “Linux Socket Filtering aka Berkeley Packet Filter (BPF) Linux Kernel Doc- umentation,” https://www.kernel.org/doc/html/v6.6/ networking/filter.html

  5. [12]

    Mininet tsn patches for integrating tsn in mininet,

    “Mininet tsn patches for integrating tsn in mininet,” https://github.com/ulbricht-inr/MininetTSN

  6. [13]

    Time coordinated compute (tcc) user guide,

    Intel, “Time coordinated compute (tcc) user guide,”

  7. [14]

    IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Sys- tems,

    “IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Sys- tems,” 2008

    2008

  8. [15]

    Intel ® 64 and IA-32 Architectures Software Developer’s Manual Volume 3B: System Programming Guide, Part 2,,

    Intel, “Intel ® 64 and IA-32 Architectures Software Developer’s Manual Volume 3B: System Programming Guide, Part 2,,”

Pith tools

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