REVIEW 3 major objections 5 minor 13 references
SkimROOT: Accelerating LHC Data Filtering with Near-Storage Processing
T0 review · 3 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash
Pith's one-line read SkimROOT reports a 44.3x end-to-end speedup over client-side filtering by running LHC event selection on a DPU attached to the storage server
desk verdict A promising DPU-based skimming prototype whose headline speedup mostly reflects moving the data path closer to storage; needs a controlled baseline and reproducibility before the broad claims can stand. read the letter →
The pith
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
The reading
What carries the argument
SkimROOT's load-bearing mechanism is the placement of the XRootD client and the filtering logic on a BlueField-3 DPU connected to the data transfer node over PCIe, with the DPU configured in Separated Host mode and receiving JSON queries over HTTP. The two-phase execution model separates filtering branches from output-only branches; the second phase runs only for events that pass, and a wildcard-minimization rule prevents patterns like HLT_* from pulling all hundreds of trigger branches when only a small set is needed. The DPU's hardware decompression engine accelerates basket decompression, and because the DPU is on the same fast PCIe link as the XRootD server, it keeps the deserialization pipeline fed while only the small filtered file crosses the WAN.
What would settle it
Repeat the same filtering task over a 1 Gbps link with many concurrent SkimROOT requests sharing one DPU and compare aggregate throughput with the same number of parallel client-side filtering processes; if the per-job speedup falls toward 1x, the near-storage benefit is a single-stream effect rather than a general property.
Extended reading notes
Core claim
The paper's core contribution is a measured end-to-end comparison. Over a 1 Gbps link, SkimROOT filters a 5 GB LZ4-compressed NanoAOD file with 1749 branches, using 27 branches for filtering and 89 for output, in 8.62 seconds, versus 382.1 seconds for unmodified client-side LZ4 filtering and 155.9 seconds for optimized client-side filtering. SkimROOT is also 3.18x faster than server-side filtering, which suffers from the absence of TTreeCache prefetching for local ROOT reads. The authors attribute the gains to three design choices: executing the filtering program on the DPU's ARM cores near storage, a two-phase branch-loading scheme that defers output-only branches until an event passes selection, and hardware-accelerated decompression. They present this as the first prototype of LHC data filtering on a DPU.
Load-bearing premise
The headline result comes from one single-threaded job fetching one NanoAOD file over a bandwidth-throttled link, and it stands in for real production skimming workloads; if production skims involve many concurrent jobs, local storage contention, or CPU-bound selection, the 44.3x number would not transfer directly.
Editorial extensions
If this is right
- Remote skimming jobs at distributed sites would finish in seconds rather than minutes on 1 Gbps links, directly reducing analysis turnaround time.
- Network traffic between storage and compute would shrink to the size of the filtered output, 5.2 MB in the test, freeing WAN capacity for other jobs.
- The speedup narrows as link speed rises: at 100 Gbps the optimized client baseline completes in 11.5 seconds, so near-storage processing matters most where bandwidth is scarce.
- The JSON query interface would let analysts specify selections without writing low-level ROOT or C++ filtering code, lowering the barrier to efficient skims.
- Offloading filtering to the DPU reduces CPU load on both the client and the storage server, according to the paper's utilization measurements.
Reading between the lines
- I would expect the 44.3x figure to shrink under multi-job production load, where concurrent SkimROOT requests share one DPU's ARM cores and PCIe bandwidth; the single-stream measurement likely represents the upper bound of per-job gains.
- The same near-storage placement could be applied to other columnar data filtering workloads beyond high-energy physics, whenever the selection is cheap relative to the transfer cost.
- A natural next test is comparison against multi-threaded client-side filtering at high concurrency and against streaming partial-read methods, to isolate whether the win comes from near-storage placement or from the two-phase branch optimization.
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. SkimROOT is a near-storage filtering system for HEP ROOT/NanoAOD data. It runs an XRootD client and a ROOT-based filter on an NVIDIA BlueField-3 DPU attached to the storage server, accepts user queries as JSON, loads only the branches needed for filtering, defers output-only branch reads until an event passes selection, and uses the DPU's hardware LZ4 decompression. The evaluation compares end-to-end filtering latency of a single NanoAOD file under throttled 1/10/100 Gbps links. At 1 Gbps, SkimROOT completes in 8.62 s versus 382.1 s for client-side LZ4 filtering (a 44.3x speedup), and it reports a 3.18x advantage over server-side filtering. The paper also reports CPU utilization for the original, optimized client-side, server-side, and SkimROOT configurations.
Significance. If the reported gains are robust across realistic WLCG workloads, the system is a meaningful step toward reducing data movement in HL-LHC skimming. The prototype is concrete, the operation breakdown in Figure 4b is informative, and the two-phase branch-loading optimization is sensible. The paper also provides one of the first detailed decompositions of filtering latency into fetch, decompression, deserialization, and output transfer, which is useful for the community. However, the significance is currently bounded by the narrow evaluation: one file, one thread, no reported variance, and no released artifact. The central quantitative claim needs stronger support before the headline speedup can be taken as representative of WLCG filtering.
major comments (3)
- [Section 4, Figure 4a] The headline '44.3x' compares SkimROOT, which reads the file from local PCIe-attached storage and sends only the 5.2 MB output over the WAN, against a client-side baseline that fetches all baskets over a throttled 1 Gbps WAN link. The paper's own 100 Gbps row shows Client Opt LZ4 at 11.5 s versus SkimROOT at 8.62 s, a 1.33x gap, so the 44.3x number mostly measures the difference between 1 Gbps WAN fetch and local PCIe access rather than DPU filtering capability. The statement that 1 Gbps is the 'primary' WLCG scenario is asserted, not demonstrated. Please add a co-located client baseline (e.g., the client reading the same file from local disk or from a local XRootD server) and either a workload survey or a sensitivity analysis to justify the bandwidth assumption.
- [Section 4, Near-Storage Filtering Latency paragraph] The 3.18x advantage over server-side filtering rests on the claim that TTreeCache does not function for local ROOT file access, so server-side filtering reads baskets one at a time. The manuscript does not test a server-side filter that reads through a local XRootD loopback or an equivalent prefetching mechanism. Without such a control, the comparison may reflect a caching artifact rather than a benefit of DPU placement. Please measure at least one prefetch-enabled server-side configuration and report its latency.
- [Section 4, first paragraph] The experimental description reports no repetition count, error bars, or variance for the latency and CPU-utilization measurements. All central claims come from one NanoAOD file, one thread, and one set of conditions, and Figures 4 and 5 show single values per condition. Since the high-bandwidth margin is small (11.5 s versus 8.62 s at 100 Gbps), repeated runs and at least one additional file or workload are needed before the speedup can be treated as stable.
minor comments (5)
- [Section 3.1] The quoted JSON example contains a stray quotation mark after 'force_all': "force_all": true" should be "force_all": true.
- [References] References [4], [5], and [9] are incomplete: they lack paper titles and, in some cases, the conference or journal name.
- [Figure 4b] The legend for Figure 4b is not described in the text; the reader must infer which bar corresponds to each method, so please add an explicit legend or a caption that names all four configurations.
- [Figure 5b] The CPU utilization percentages are reported as single numbers per component; please state how utilization was sampled (e.g., average over the run, sampling interval).
- [Section 2.3 vs. Section 4] The BF-3 is described as supporting PCIe Gen 5.0 x32, but the evaluation says the server/DPU link is limited by the server's PCIe Gen 3.0; please clarify whether the 128 Gb/s figure is the measured effective bandwidth or a theoretical maximum.
Circularity Check
SkimROOT's 44.3x claim rests on independent measurements against external baselines; no derivation reduces to its inputs.
full rationale
The paper's central claims are empirical latency comparisons made against external baselines. SkimROOT's 8.62 s latency, the client-side 382.1 s LZ4 baseline, the optimized 155.9 s baseline, and the server-side 18 s basket fetch are all measured values from an evaluation harness with a fixed NanoAOD file and network emulation, not quantities derived from each other by definition. The 44.3x speedup and 3.18x improvement are simple ratios of these measurements, so no equation is fit to the target result and no metric is defined in terms of the claimed outcome. The main caveats are external-validity concerns, not circularity: the single-stream, single-client evaluation, the 1 Gbps WAN emulation via Wondershaper, and the absence of a co-located client baseline mean the headline speedup partly reflects the asymmetry between local PCIe-class storage access and throttled remote WAN fetch. However, a bandwidth-bound comparison is a legitimate experimental setup, and the paper transparently reports the 100 Gbps case where the advantage shrinks. No load-bearing step reduces to a self-citation, an ansatz imported from prior work, or a fitted parameter renamed as a prediction; the paper is self-contained against independent benchmarks.
Assumptions & free parameters
assumptions (4)
- domain assumption ROOT TTree stores event rows across column branches, with compressed baskets as the access unit and TTreeCache prefetching improving remote access.
- domain assumption Wondershaper bandwidth throttling on a single link faithfully emulates remote WAN conditions at 1, 10, and 100 Gbps.
- domain assumption The DPU's ARM cores and hardware decompression engine achieve comparable or better filtering performance than the host CPU in this workload.
- domain assumption The filtering criteria and branch sets (27 filtering branches and 89 output branches) are representative of real CMS Higgs analysis skims.
Cite this review
Pith. "Pith review of SkimROOT: Accelerating LHC Data Filtering with Near-Storage Processing." pith.science (2026). https://pith.science/paper/MFPU53U2
@misc{pith2026250604507,
author = {Pith},
title = {Pith review of: SkimROOT: Accelerating LHC Data Filtering with Near-Storage Processing},
year = {2026},
howpublished = {\url{https://pith.science/paper/MFPU53U2}},
note = {Machine review of arXiv:2506.04507}
}
abstract
Data analysis in high-energy physics (HEP) begins with data reduction, where vast datasets are filtered to extract relevant events. At the Large Hadron Collider (LHC), this process is bottlenecked by slow data transfers between storage and compute nodes. To address this, we introduce SkimROOT, a near-data filtering system leveraging Data Processing Units (DPUs) to accelerate LHC data analysis. By performing filtering directly on storage servers and returning only the relevant data, SkimROOT minimizes data movement and reduces processing delays. Our prototype demonstrates significant efficiency gains, achieving a 44.3$\times$ performance improvement, paving the way for faster physics discoveries.
Figures
Figures from the paper (2 more)
Reference graph
Works this paper leans on
-
[1]
CMS Collaboration, JINST 3, S08004 (2008)
work page 2008
-
[2]
ATLAS Collaboration, JINST 3, S08003 (2008)
work page 2008
-
[3]
CERN IT Department, Cern data centre: Key information (2021), accessed: Febru- ary 2025, https://information-technology.web.cern.ch/sites/default/ files/CERNDataCentre_KeyInformation_Nov2021V1.pdf
work page 2021
-
[4]
O. Gutsche, L. Canali, I. Cremer, M. Cremonesi, P. Elmer, I. Fisk, M. Girone, B. Jay- atilaka, J. Kowalkowski, V . Khristenko et al.,1085, 042030 (2018)
work page 2018
- [5]
-
[6]
B. Galewsky, R. Gardner, L. Gray, M. Neubauer, J. Pivarski, M. Pro ffitt, I. Vukotic, G. Watts, M. Weinberg,245, 04043 (2020)
work page 2020
-
[7]
O. Brüning, L. Rossi, in The High Luminosity Large Hadron Collider: New Machine for Illuminating the Mysteries of the Universe (World Scientific, 2024), pp. 1–53
work page 2024
-
[8]
CMS O ffline Software and Computing, Tech. Rep. CMS-NOTE-2022-008, CERN, Geneva (2022), https://cds.cern.ch/record/2815292
arXiv 2022
Show all 13 references
-
[9]
Ellis, C
K. Ellis, C. Brew, G. Patargias, T. Adye, R. Appleyard, A. Dewhurst, I. Johnson, 245, 04006 (2020)
2020
-
[10]
R. Brun, F. Rademakers, Nuclear Instruments and Methods in Physics Research Section A: Accelerators, Spectrometers, Detectors and Associated Equipment 389, 81 (1997), new Computing Techniques in Physics Research V
1997
-
[11]
NVIDIA Corporation, Nvidia bluefield-3 datasheet (2025), ac- cessed: 2025-02-16, https://resources.nvidia.com/ en-us-accelerated-networking-resource-library/ datasheet-nvidia-bluefield
2025
-
[12]
NVIDIA Corporation, NVIDIA DOCA SDK Overview (2025), accessed: 2025-02-16, https://docs.nvidia.com/doca/sdk/doca+overview/index.html
2025
-
[13]
Kaseorg, Wondershaper: Simple tra ffic shaping script , https://github.com/ magnific0/wondershaper (2021), accessed: 2025-04-14
A. Kaseorg, Wondershaper: Simple tra ffic shaping script , https://github.com/ magnific0/wondershaper (2021), accessed: 2025-04-14
2021
Reviewed August 7, 2026 · model on record in the stance chip above.
Discussion (0). Sign in to comment.