{"id":"97154a3c-6ab4-42b4-9e9c-d9e368f8c4a9","arxiv_id":"2506.04507","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A DPU-based near-storage filtering prototype reports 44.3x lower latency than client-side LHC data filtering on a 1 Gbps link.","lead":"SkimROOT filters Large Hadron Collider data on a programmable network card inside the storage server, sending only the small filtered result to the analysis machine. The prototype reports a 44.3x speedup over ordinary client-side filtering on a simulated 1 Gbps remote link, which could shorten physics-analysis waits that currently last days.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"44.3x claim conflates WAN-to-local bandwidth with DPU filtering; the test never isolates a co-located client baseline or verifies that 1 Gbps remote WAN fetch is representative.","rationale":"The reader's weakest assumption is that the evaluation setup represents real WLCG workloads, and I agree that representativeness is the key open question. My stress-test sharpens that concern: the 44.3x number is not merely an extrapolation to a different workload, it is structurally determined by the comparison's network asymmetry. The paper's own 100 Gbps result shows the DPU advantage over optimized client-side filtering shrinks to about 1.33x, so the headline gain is contingent on the 1 Gbps remote-fetch assumption. I also flag a concrete internal confound: the advantage over server-side filtering appears to rest on TTreeCache being unavailable for local ROOT reads, which may be fixable and is not tested. These are addressable with simple control experiments, so they do not change the CONDITIONAL verdict; they strengthen it by identifying exactly which measurements would validate or falsify the central claim.","tokens_in":6894,"tokens_out":5908,"duration_ms":75518,"concrete_test":"Rerun the identical filtering workload with the optimized client-side code on a node co-located with the storage server (or with a local file copy), keeping the same TTreeCache and single-threaded settings. If the co-located client latency drops from 155.9s toward SkimROOT's 8.62s, the 44.3x headline is mainly a WAN-to-local bandwidth artifact. Additionally, run server-side filtering with a localhost XRootD server (so TTreeCache/prefetching is active) and compare against SkimROOT; if server-side latency approaches 8.62s, the claimed 3.18x near-storage advantage over server-side filtering is an artifact of disabled prefetching rather than DPU processing.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The headline speedup is computed by changing the data path: client-side baselines fetch baskets over a throttled 1 Gbps WAN link, while SkimROOT reads the same file from the local XRootD server at PCIe speed (up to 128 Gbps) and sends only the 5.2 MB output over the WAN. The paper's own Figure 4a shows Client Opt LZ4 at 155.9s over 1 Gbps, but at 100 Gbps that baseline drops to 11.5s, making SkimROOT's advantage only ~1.33x. Thus the 44.3x gain mostly measures the bandwidth asymmetry between remote WAN fetch and local PCIe access, not the DPU's filtering capability. The paper provides no evidence that 1 Gbps remote WAN fetch is the dominant WLCG scenario; modern sites often have 100 Gbps links, and workload schedulers commonly place jobs near data. If jobs read local or cached data, the claimed speedup largely disappears. A second, related soft spot is the 3.18x advantage over server-side filtering: the paper attributes this to TTreeCache not functioning for local ROOT file access, but it does not test whether a localhost XRootD loopback or any equivalent prefetching mechanism makes server-side filtering comparable. Both unmeasured possibilities could substantially shrink the central claimed advantage.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":7108,"tokens_out":5813,"duration_ms":50539,"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":[{"comment":"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":"Section 4, Figure 4a"},{"comment":"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":"Section 4, Near-Storage Filtering Latency paragraph"},{"comment":"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.","section":"Section 4, first paragraph"}],"minor_comments":[{"comment":"The quoted JSON example contains a stray quotation mark after 'force_all': \"force_all\": true\" should be \"force_all\": true.","section":"Section 3.1"},{"comment":"References [4], [5], and [9] are incomplete: they lack paper titles and, in some cases, the conference or journal name.","section":"References"},{"comment":"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.","section":"Figure 4b"},{"comment":"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":"Figure 5b"},{"comment":"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.","section":"Section 2.3 vs. Section 4"}],"recommendation":"major_revision","confidential_remarks":"The stress-test concern about bandwidth conflation is the right one and is not fully addressed by the current text. I would not reject on this basis because the architectural comparison is legitimate for a near-storage system, but the authors should be required to add a co-located client baseline and report variance before the 44.3x claim can be accepted as representative."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Worth a read, but the headline 44.3x is not as clean as it sounds. What's genuinely new: first DPU-based ROOT filtering prototype, a JSON query interface, a two-phase branch-loading model, and a clear breakdown of where filtering time actually goes. The system design is sensible, and the arithmetic in Section 4 checks out. The comparison to server-side filtering (3.18x) is more informative because both sides read local data, though even that suffers from the TTreeCache local-access limitation.\n\nThe main soft spot is the comparison itself. Client-side baselines fetch baskets over a throttled 1 Gbps WAN, while SkimROOT reads the same file from a local XRootD server over PCIe. Their own Figure 4a shows Client Opt LZ4 dropping to 11.5s at 100 Gbps, only about 1.33x slower than SkimROOT's 8.62s. So the 44.3x mostly measures bandwidth asymmetry, not DPU filtering capability. That is not fatal—near-storage processing is supposed to change the data path—but the paper should say so and stop asserting a blanket 44.3x speedup. It also does not test a realistic production setting: many concurrent jobs, cached or local reads, or CPU-bound selection. Single file, single thread, single run, no error bars—the numeric claims are fragile.\n\nThe second real gap is reproducibility. No artifact, no code, no data. For a systems paper, that matters. The two-phase execution and wildcard minimization are useful ideas, and the breakdown showing deserialization dominating unoptimized client filtering is a nice contribution on its own.\n\nBottom line: I would send this to peer review—the combination is new and the direction is relevant for HL-LHC—but I would require a redesign of the evaluation: a co-located client baseline at equal network distance, multiple files and runs, and a released artifact. The core idea holds; the evidence is too thin for the broad claims.","headline":"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.","tokens_in":7691,"tokens_out":2053,"would_cite":true,"duration_ms":21685,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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","keywords":["near-storage processing","DPU","ROOT data filtering","LHC data reduction","skimming","XRootD","hardware decompression","columnar data"],"falsifier":"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.","tokens_in":6679,"feed_emoji":"⚡","tokens_out":7347,"duration_ms":67454,"temperature":0.7,"pith_summary":"SkimROOT is a prototype that moves LHC data filtering onto a DPU, a programmable network and storage card, attached to the data server. The central claim is that by selecting events at the storage source, only the reduced ROOT file crosses the wide-area network, and the paper reports that on a 1 Gbps link its prototype completes the evaluated filtering task in 8.62 seconds versus 382.1 seconds for ordinary client-side filtering of the same LZ4-compressed file, a 44.3x speedup. This matters because LHC data volumes are projected to grow roughly tenfold in the HL-LHC era, and skimming is a recurring first step in nearly every analysis. If the result holds under production conditions, it would shorten analysis turnaround and reduce network load across distributed computing sites.","feed_headline":"Near-storage DPU filtering speeds LHC skimming 44.3x","feed_subtitle":"SkimROOT runs event selection on a DPU at the storage server, so only the small filtered result crosses the network.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Provides ROOT's TTree columnar storage and basket I/O model that SkimROOT's two-phase branch loading optimizes.","marker":"[10]"},{"why":"Specifies the BlueField-3 DPU hardware, including ARM cores, hardware decompression engine, PCIe and NIC capabilities, used as the execution platform.","marker":"[11]"},{"why":"Provides the DOCA framework used to program the DPU and offload decompression to its hardware engine.","marker":"[12]"},{"why":"Throttles the link in the evaluation to emulate the 1, 10, and 100 Gbps WAN conditions used in all reported latency measurements.","marker":"[13]"}],"fun_headline_variants":["DPU at the storage node makes LHC skim 44x faster","SkimROOT cuts LHC skim time 44.3x with near-storage DPU","Run LHC event filter on DPU: 44.3x faster skimming","Near-storage DPU filtering yields 44.3x LHC skim speedup","Storage-side DPU accelerates LHC data reduction 44.3x"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["DPU at the storage node makes LHC skim 44x faster","SkimROOT cuts LHC skim time 44.3x with near-storage DPU","Run LHC event filter on DPU: 44.3x faster skimming","Near-storage DPU filtering yields 44.3x LHC skim speedup","Storage-side DPU accelerates LHC data reduction 44.3x"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000387,"raw_usage":{"total_tokens":1995,"prompt_tokens":852,"completion_tokens":1143,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":468,"completion_tokens_details":{"reasoning_tokens":1035}},"tokens_in":468,"tokens_out":1143,"duration_ms":23050,"temperature":1.0,"reasoning_tokens":1035,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T10:40:59.255264+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides ROOT's TTree columnar storage and basket I/O model that SkimROOT's two-phase branch loading optimizes."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Specifies the BlueField-3 DPU hardware, including ARM cores, hardware decompression engine, PCIe and NIC capabilities, used as the execution platform."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the DOCA framework used to program the DPU and offload decompression to its hardware engine."},{"cited_title":"Kaseorg, Wondershaper: Simple tra ffic shaping script , https://github.com/ magnific0/wondershaper (2021), accessed: 2025-04-14","cited_arxiv_id":null,"evidence_quote":"Throttles the link in the evaluation to emulate the 1, 10, and 100 Gbps WAN conditions used in all reported latency measurements."}],"review_version":1}