Pith. sign in

REVIEW 4 major objections 5 minor 35 references

A Study on Messaging Trade-offs in Data Streaming for Scientific Workflows

T0 review · 4 major / 5 minor · reviewed 2026-08-04 · deepseek-v4-flash

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

Pith's one-line read Reliability mechanisms in RabbitMQ can cost up to 81% of streaming throughput, and batching recovers most of the loss.

desk verdict Useful, reproducible RabbitMQ tuning study whose central reliability-tax numbers conflate synchronous waiting with reliability; the ack/prefetch/multi-queue findings are solid. read the letter →

arxiv 2509.07199 v1 pith:UDSC7BCH submitted 2025-09-08 cs.DC

Anjus George , Michael J. Brim , Christopher Zimmer , Tyler J. Skluzacek , A.J. Ruckman , Gustav R. Jansen , Sarp Oral This is my paper · ORCID
classification cs.DC
keywords datastreamingRabbitMQscientificworkflowsmessagingreliabilitypublisherconfirmsconsumeracknowledgementsprefetchqueueparallelism
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

Scientists increasingly want to stream data directly from experimental instruments into HPC memory, but reliable delivery usually seems to conflict with speed. This paper shows, through RabbitMQ simulations of two representative workflows (Deleria's small batched messages and LCLS's 1 MiB files), that the conflict is mostly configurable: synchronous per-message publisher confirms cost up to 81% of throughput, while batching confirms, batching consumer acknowledgements, raising prefetch, and using a small number of parallel queues recover 4.6x to 6.1x. If the simulations hold, workflow users can provision reliable streaming without expensive trial-and-error on real instruments. The paper's contribution is a mapping from tunable RabbitMQ parameters to the reliability-throughput trade-off for these two workloads.

What carries the argument

The central mechanism is the round-trip cost of each reliability handshake between producer/consumer and broker. Synchronous confirms, per-message acknowledgements, and persistence-with-confirms each force a wait on the critical path; batching confirms or acks amortizes that wait over many messages; raising prefetch keeps messages in flight during the wait; and parallel queues give the broker additional CPU cores, since RabbitMQ's hot path for one queue uses one core. This round-trip-amortization model does the explanatory work across all six experiments.

What would settle it

Run the same parameter sweep against live Deleria traffic with variable event batching and against LCLS on a 100 Gbps link; if the 81% sync-confirm penalty, 4.6x batching gain, or 6.1x multi-queue gain do not approximately reproduce, the paper's central characterization fails.

Watch

Extended reading notes

Core claim

Using a purpose-built simulator that drives RabbitMQ with synthetic Deleria and LCLS workloads, the paper establishes that every reliability mechanism it tests taxes throughput through added round-trips, and that the tax can be amortized. Per-message synchronous publisher confirms reduce Dstream throughput by up to 81% and Lstream by up to 37%; batching 64 confirms at a time improves Dstream 4.6x. Batch consumer acknowledgements (64 messages) give up to 2.7x over per-message acks and near-auto-ack throughput for Deleria. Prefetch alone, with per-message acks, improves throughput 2.5x (Dstream) and 2x (Lstream). And 2-4 parallel queues outperform both one queue and many queues: 6.1x (Dstream)

Load-bearing premise

The measured rankings and gain factors transfer to real experiments only if the synthetic workloads are faithful: Deleria's fixed 16 KiB messages and steady 1 MiB LCLS messages on the tested 1 Gbps link.

Editorial extensions

If this is right

  • Combine batched publisher confirms with batched consumer acknowledgements and a prefetch count around 64 for Deleria-style traffic to get near-unreliable-mode throughput with full per-message reliability guarantees.
  • For LCLS-style 1 MiB messages over 1 Gbps, network bandwidth saturates at four consumers, so further consumer scaling or queue parallelism will not help until the network is upgraded.
  • Durability alone costs little on classic queues; the expensive case is guaranteed persistence, which combines persistence with synchronous confirms and can cut throughput by up to 67%.
  • The best queue count is a small fraction of consumer count, not equality; 2-4 queues outperform 64 queues, because RabbitMQ queue management overhead dominates at high queue counts.
  • Configuration selection for these workflows is non-obvious and depends on consumer count, message size, and server resources; simulation is a practical substitute for costly instrument time.

Reading between the lines

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

  • If the round-trip-amortization model is the true cause, the same qualitative ranking should hold for other RabbitMQ workloads, but the optimal prefetch and batch sizes should scale with message size and network latency; that is testable outside this paper.
  • A likely extension the authors did not run is a mixed-message-size workload matching Deleria's real variable event batching; variable sizes may shift the optimal batch size and the measured gain factors.
  • The 1 Gbps bottleneck means the LCLS results mostly characterize network saturation rather than RabbitMQ's internal costs; rerunning on 100 Gbps would likely change the saturation point and reveal whether multi-queue gains persist for large messages.
  • Because DS2HPC also provisions Redis, an equivalent parameter sweep on Redis would show whether these reliability-versus-throughput trade-offs are framework-specific or general.
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

4 major / 5 minor

Summary. The paper studies RabbitMQ messaging configuration trade-offs for two synthetic scientific streaming workloads, Deleria ('Dstream', 16 KiB messages) and LCLS ('Lstream', 1 MiB messages), on OLCF's DS2HPC testbed. Using a custom Go simulator and a three-node RabbitMQ 4.0.5 cluster, the authors vary one tunable at a time—publisher confirms, durability, consumer acknowledgements, prefetch count, and multi-queue parallelism—and report normalized aggregate consumer throughput. The central claim is that reliability mechanisms impose a large, configurable throughput tax (e.g., up to 81% reduction for synchronous per-message confirms on Dstream), which can be largely recovered via batching confirms/acks, higher prefetch, and a small number of parallel queues (up to 6.1x improvement).

Significance. The paper makes a pragmatic contribution by providing a reproducible simulation harness (publicly available code and configuration files) and a first-order map of RabbitMQ parameters for IRI-style scientific streaming. If the reliability-tax conclusion were sound, the guidance would help DS2HPC users avoid expensive real-instrument trial and error. However, the central interpretation is undermined by a conflation of synchronous waiting with reliability: RabbitMQ's asynchronous publisher confirms are dismissed as 'least reliable' even though a correctly implemented async-confirm client obtains the same end-to-end delivery guarantee without putting per-message RTT on the critical path. The measured 81% / 4.6x figures therefore quantify a blocking-wait cost, not a reliability cost. The Lstream results are additionally dominated by a 1 Gbps link bottleneck that the paper itself acknowledges. With corrected experiments and more cautious claims, the study could still be useful, but the headline message as written is not established.

major comments (4)
  1. [§4.2.1, §5.2] The core 'reliability tax' claim conflates synchronous confirmation with reliability. RabbitMQ publisher confirms are asynchronous by design: a producer can publish continuously, track delivery tags, and wait only at shutdown/checkpoint, obtaining the same loss detection as synchronous per-message confirms. The paper labels async confirms 'least reliable' (§4.2.1) and observes in Figure 3 that they give essentially no-confirm throughput, which confirms that non-blocking confirm processing is cheap. The up-to-81% reduction for 'Sync (per msg)' and the 4.6x batching recovery in Figure 4 thus measure the cost of a per-message synchronous wait, not the cost of reliable delivery. The authors should either rerun the reliability comparison with a properly implemented async-confirm producer that actually drains confirmations, or reframe the claim as 'synchronous per-message waiting imposes a tax
  2. [§5.2, §5.6, §6] The Lstream results are dominated by the 1 Gbps Ethernet link between Andes and the DSNs. The paper states in §5.2 that throughput saturates at 4 consumers 'due to network bandwidth limitations,' and §6 acknowledges that the DSNs' 100 Gbps interfaces were not yet usable. Under link saturation, the claimed differences—37% sync-confirm reduction, ~50% batch improvement, 5.3x multi-queue gain—are not clean measurements of RabbitMQ parameter effects; they partly reflect contention for a saturated link. The conclusions for Lstream should be explicitly scoped as 1 Gbps-limited, or the experiments should be re-run on a higher-bandwidth path before making workflow-specific recommendations.
  3. [§5.1, Table 1] The synthetic workload model fixes Dstream to 16 KiB messages (2 KiB/event, 8 events) and Lstream to 1 MiB messages, despite Table 1 stating that Deleria's payload size and events-per-message are variable. This simplification is disclosed, but it is load-bearing for the quantitative transferability claim: the batching and prefetch improvements for Dstream (2.5x–4.6x) depend on many small messages being amortizable. No variance or confidence information is reported—each data point is the mean of three runs with no error bars or raw values—so the reader cannot judge whether the reported differences (e.g., the 4.6x figure at 64 consumers) are statistically meaningful. At minimum, the paper should show per-run spread or error bars and state the coefficient of variation.
  4. [§5.3] The durability experiment repeats the same sync-wait conflation. The 'guaranteed persistence' condition ('With sync confirm and persistence') combines persistence with synchronous per-message confirms; the up-to-67% throughput reduction is again attributable to blocking waits, not to persistence itself. The paper even notes that with persistence alone, messages can still be lost if the broker crashes before flush, so the only meaningful durability guarantee tested is the sync-confirm variant. An async-confirm producer with persistent messages, waiting at the end of the run, would provide the same guarantee at substantially higher throughput. The durability section should be revised to separate disk-flush cost from confirmation-wait cost.
minor comments (5)
  1. [Figures 3–8] All figures report normalized means of three runs with no error bars or variance. Please add at least min/max error bars or a supplementary table with raw message-per-second values, especially for the headline 4.6x and 6.1x claims.
  2. [§4.2.1] The term 'least reliable' for asynchronous confirms is inaccurate; async confirms provide the same broker-delivery guarantee if the client processes confirmations. Consider calling it 'non-blocking confirm processing' or 'confirms without synchronization.'
  3. [§5.6] The multi-queue experiment changes the ordering (producers started first, queues pre-filled) relative to all other experiments. This methodological difference should be stated more prominently, as it affects comparability with the other parameter sweeps.
  4. [§5.2, Figure 4] The x-axis label and caption should clarify that the baseline for Figure 4 is sync per-message confirms, not the no-confirm default used in Figure 3. Currently the reader must infer this from the text.
  5. [General] Minor typographical and formatting issues: 'simulations' is used where 'simulation experiments' would be clearer; Table 2 lists 'synchronous confirms for per message and batch of messages' but the distinction between sync-batch and async-batch is not discussed in §4.2.1.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper reports direct throughput measurements under disclosed configurations; no fitted parameter is renamed as a prediction and no load-bearing step reduces to its own input.

full rationale

The paper's central claims are empirical measurements of RabbitMQ throughput under different publisher-confirm, durability, acknowledgement, prefetch, and multi-queue configurations. There is no derivation chain in which an output quantity is constructed from the same data it is claimed to predict. The authors do not fit any parameter to a subset of results and then 'predict' a closely related quantity; instead they vary one tunable parameter at a time and report measured aggregate throughput, normalized to a stated baseline. The workload characteristics (Table 1) and the fixed 16 KiB Deleria message size are disclosed modeling assumptions, not fitted inputs that pre-determine the measured rankings. The 4.6x and 6.1x improvement numbers are direct comparisons of measured configurations (sync per-message confirms vs. batch confirms; single queue vs. two queues), not quantities implied by the simulator's construction. The paper's self-citations (e.g., [7], [27]) describe the DS2HPC infrastructure and S3M but are not used to justify the throughput trade-off conclusions; the trade-offs stand on the reported experiments. The skeptical concern that async confirms can already provide reliability without blocking is a validity threat to the generalization that 'reliability imposes a large tax', but it is not a circularity: the paper's measured throughput values are not equivalent by definition to its conclusions. No circular step can be exhibited from the text, so the appropriate finding is no significant circularity.

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

The central claims rest on workload simplification choices and RabbitMQ's documented semantics, not on fitted parameters or new physical entities. The main unvalidated inputs are the synthetic workload characteristics and the 1 Gbps testbed assumption.

free parameters (2)
  • Dstream fixed message size = 16 KiB (2 KiB per event x 8 events per message)
    Chosen in Section 5.1 to make Deleria's variable payload concrete. Real Deleria messages vary in size and events per message, so this choice shapes all Dstream throughput numbers.
  • Baseline configuration = No confirms, no durability, automatic acknowledgements, prefetch count 1, single queue
    All normalized throughput ratios are relative to this hand-chosen baseline defined in Section 5.1. A different baseline would change the displayed gains for every parameter.
assumptions (3)
  • domain assumption RabbitMQ classic queues behave as documented: small in-memory buffering, delayed disk writes, and no replication
    Sections 4.1.2 and 5.3 interpret the persistence results as RabbitMQ optimizations. If actual RabbitMQ 4.0.5 semantics differ under load, the durability conclusions would not follow.
  • domain assumption Synthetic workloads with steady rates and fixed payload sizes are representative enough of Deleria and LCLS
    Table 1 and Section 5.1 fix Deleria to 16 KiB messages and LCLS to 1 MiB messages on a 1 Gbps link. Real Deleria message sizes vary, and LCLS-II targets far higher rates, as the authors acknowledge in Section 6.
  • ad hoc to paper Throughput measured on a 1 Gbps Ethernet link between Andes and DSNs captures the trade-offs of interest
    Lstream saturation above a few consumers is attributed to the 1 Gbps link in Sections 5.2 and 6. With 100 Gbps networking, the relative rankings could change.

how reviews work

0 comments
Cite this review

Pith. "Pith review of A Study on Messaging Trade-offs in Data Streaming for Scientific Workflows." pith.science (2026). https://pith.science/paper/UDSC7BCH

@misc{pith2026250907199,
  author       = {Pith},
  title        = {Pith review of: A Study on Messaging Trade-offs in Data Streaming for Scientific Workflows},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/UDSC7BCH}},
  note         = {Machine review of arXiv:2509.07199}
}
read the original abstract

Memory-to-memory data streaming is essential for modern scientific workflows that require near real-time data analysis, experimental steering, and informed decision-making during experiment execution. It eliminates the latency bottlenecks associated with file-based transfers to parallel storage, enabling rapid data movement between experimental facilities and HPC systems. These tightly coupled experimental-HPC workflows demand low latency, high throughput, and reliable data delivery to support on-the-fly analysis and timely feedback for experimental control. Off-the-shelf messaging frameworks are increasingly considered viable solutions for enabling such direct memory streaming due to their maturity, broad adoption, and ability to abstract core messaging and reliability functionalities from the application layer. However, effectively meeting the workflows' requirements depends on utilizing the framework's capabilities and carefully tuning its configurations. In this paper, we present a study that investigates the messaging parameters, and their configuration choices that impact the streaming requirements of two representative scientific workflows. We specifically characterize throughput trade-offs associated with reliable message transmission for these workflows. Our study is conducted through streaming simulations using synthetic workloads derived from the Deleria and LCLS workflows, employing the RabbitMQ messaging framework within the context of the Data Streaming to HPC infrastructure at OLCF. Our simulations reveal several key observations and practical insights that help users understand which configurations best meet the needs of their streaming workloads.

Figures

Figures reproduced from arXiv: 2509.07199 by the authors.

Figure 1
Figure 1. Data Streaming to HPC (DS2HPC) architecture at [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Producers (𝑃1 and 𝑃2) and consumers (𝐶1 and 𝐶2) using a queue implemented by a RabbitMQ server. RabbitMQ is a messaging broker that implements the Advanced Message Queuing Protocol (AMQP) [8] as its wire-level commu￾nication protocol. A RabbitMQ server (broker) enables clients to send, receive, or temporarily store messages using queues (i.e., or￾dered collections of messages that are held until consumed). As shown … view at source ↗
Figure 5
Figure 5. Throughput for varying message durability: no [PITH_FULL_IMAGE:figures/full_fig_p007_5.png] view at source ↗
Figures from the paper (4 more)
Figure 4
Figure 4. Figure 4: Throughput for synchronous publisher confirms [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]
Figure 6
Figure 6. Figure 6: Throughput for consumer acknowledgment strate [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]
Figure 7
Figure 7. Figure 7: Throughput for different prefetch counts for (a) [PITH_FULL_IMAGE:figures/full_fig_p008_7.png]
Figure 8
Figure 8. Figure 8: Throughput for single- vs. multi-queue configurations with parallel consumption for (a) Dstream and (b) Lstream. [PITH_FULL_IMAGE:figures/full_fig_p009_8.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

35 extracted references · 30 canonical work pages

  1. [1]

    Hasan Abbasi, Matthew Wolf, Greg Eisenhauer, Scott Klasky, Karsten Schwan, and Fang Zheng. 2009. Datastager: scalable data staging services for petascale applications. InProceedings of the 18th ACM international symposium on High performance distributed computing. 39–48

    work page 2009

  2. [2]

    2025.Redis Docs

    Redis Authors. 2025.Redis Docs. Retrieved June 26, 2025 from https://redis.io/ docs/latest/

    work page 2025

  3. [3]

    Pandu Rangan

    Ashwinkumar Badanidiyuru, Arpita Patra, Ashish Choudhury, Kannan Srinathan, and C. Pandu Rangan. 2012. On the trade-off between network connectivity, round complexity, and communication complexity of reliable message transmission.J. ACM59, 5, Article 22 (Nov. 2012), 35 pages. doi:10.1145/2371656.2371657

    work page arXiv 2012

  4. [4]

    Alexander Brace, Igor Yakushin, Heng Ma, Anda Trifan, Todd Munson, Ian Foster, Arvind Ramanathan, Hyungro Lee, Matteo Turilli, and Shantenu Jha

    work page

  5. [5]

    Wes Brewer, Ana Gainaru, Frédéric Suter, Feiyi Wang, Murali Emani, and Shantenu Jha. 2025. AI-coupled HPC Workflow Applications, Middleware and Performance. arXiv:2406.14315 [cs.DC] https://arxiv.org/abs/2406.14315

    work page Pith review arXiv 2025

  6. [6]

    Brim, Lance Drane, Marshall McDonnell, Christian Engelmann, and Addi Malviya Thakur

    Michael J. Brim, Lance Drane, Marshall McDonnell, Christian Engelmann, and Addi Malviya Thakur. 2024. A Microservices Architecture Toolkit for Intercon- nected Science Ecosystems. InSC24-W: Workshops of the International Conference for High Performance Computing, Networking, Storage and Analysis. 2072–2079. doi:10.1109/SCW63240.2024.00259

    arXiv 2024

  7. [7]

    Brim, Anjus George, Amir Shehata, Corwin Lester, David Rogers, Patrick Widener, Ross Miller, Gustav Jansen, Rafael Ferreira Da Silva, and Sarp Oral

    Michael J. Brim, Anjus George, Amir Shehata, Corwin Lester, David Rogers, Patrick Widener, Ross Miller, Gustav Jansen, Rafael Ferreira Da Silva, and Sarp Oral. 2024.A High-level Design for Bidirectional Data Streaming to High- Performance Computing Systems from External Science Facilities. Technical Re- port. Oak Ridge National Laboratory (ORNL), Oak Ridg...

    work page doi:10.2172/2338264 2024

  8. [8]

    2025.AMQP 0-9-1 Model Explained

    Broadcom. 2025.AMQP 0-9-1 Model Explained. Retrieved June 26, 2025 from https://www.rabbitmq.com/tutorials/amqp-concepts

    work page 2025

Show all 35 references
  1. [9]

    2025.RabbitMQ 4.1 Documentation

    Broadcom. 2025.RabbitMQ 4.1 Documentation. Retrieved June 26, 2025 from https://www.rabbitmq.com/docs

    2025

  2. [10]

    Jaime Cernuda, Jie Ye, Anthony Kougkas, and Xian-He Sun. 2024. HStream: A hierarchical data streaming engine for high-throughput scientific applications. InProceedings of the 53rd International Conference on Parallel Processing(Gotland, Sweden)(ICPP ’24). Association for Compu...

    2024

  3. [11]

    Joaquin Chung, Wojciech Zacherek, AJ Wisniewski, Zhengchun Liu, Tekin Bicer, Rajkumar Kettimuthu, and Ian Foster. 2022. SciStream: Architecture and Toolkit for Data Streaming between Federated Science Instruments(HPDC ’22). Association for Computing Machinery, New York, NY, US...

    2022

  4. [12]

    2025.Go RabbitMQ Client Library

    RabbitMQ core team. 2025.Go RabbitMQ Client Library. Retrieved June 27, 2025 from https://github.com/rabbitmq/amqp091-go/tree/main

    2025

  5. [13]

    Cromaz, Mario, Dart, Eli, Pouyoul, Eric, and Jansen, Gustav R. 2021. Simple and Scalable Streaming: The GRETA Data Pipeline*.EPJ Web Conf.251 (2021), 04018. doi:10.1051/epjconf/202125104018

    2021

  6. [14]

    Dalesio, Jeffrey O

    Leo R. Dalesio, Jeffrey O. Hill, Martin Kraimer, Stephen Lewis, Douglas Murray, Stephan Hunt, William Watson, Matthias Clausen, and John Dalesio. 1994. The experimental physics and industrial control system architecture: past, present, and future.Nuclear Instruments and Method...

    1994 doi

  7. [15]

    L R Dalesio, A J Kozubal, and M R Kraimer. 1990. EPICS architecture. Los Alamos National Lab., NM (United States). https://www.osti.gov/biblio/6110347

    1990

  8. [16]

    Etz, David M

    Brian D. Etz, David M. Rogers, Michael J. Brim, Ketan Maheshwari, Kellen Leland, Tyler J. Skluzacek, Jack Lange, Daniel Pelfrey, Jordan Webb, Patrick Widener, Ryan Adamson, Christopher Zimmer, Veronica G. Melesse Vergara, Mallikar- jun Shankar, Sarp Oral, and Rafael Ferreira d...

    2025 arXiv

  9. [17]

    Turrisi da Costa, Bruno Bogaz Zarpelão, and Sylvio Barbon Junior

    Jessica Fernandes Lopes, Everton Jose Santana, Victor G. Turrisi da Costa, Bruno Bogaz Zarpelão, and Sylvio Barbon Junior. 2020. Evaluating the Four- Way Performance Trade-Off for Data Stream Classification in Edge Computing. IEEE Transactions on Network and Service Management...

    2020

  10. [18]

    Pascuzzi, and Matteo Turilli

    Shantenu Jha, Vincent R. Pascuzzi, and Matteo Turilli. 2022. AI-coupled HPC Workflows. arXiv:2208.11745 [cs.DC] https://arxiv.org/abs/2208.11745

    2022 arXiv

  11. [19]

    Remi Lam, Alvaro Sanchez-Gonzalez, Matthew Willson, Peter Wirnsberger, Meire Fortunato, Ferran Alet, Suman Ravuri, Timo Ewalds, Zach Eaton-Rosen, Weihua Hu, Alexander Merose, Stephan Hoyer, George Holland, Oriol Vinyals, Jacklynn Stott, Alexander Pritzel, Shakir Mohamed, and P...

    2023

  12. [20]

    Addi Thakur Malviya, Seth Hitefield, Marshall McDonnell, Matthew Wolf, Richard Archibald, Lance Drane, Kevin Roccapriore, Maxim Ziatdinov, Jesse McGaha, Robert Smith, et al . 2023. Towards a Software Development Framework for Interconnected Science Ecosystems. Oak Ridge Nation...

    2023

  13. [21]

    Amil Merchant, Simon Batzner, Samuel S Schoenholz, Muratahan Aykol, Gowoon Cheon, and Ekin Dogus Cubuk. 2023. Scaling deep learning for materials discov- ery.Nature624, 7990 (2023), 80–85

    2023

  14. [22]

    Miller, Deborah Bard, Amber Boehnlein, Kjiersten Fagnan, Chin Guok, Eric Lançon, Sreeranjani Ramprakash, Mallikarjun Shankar, Nicholas Schwarz, and Benjamin L

    William L. Miller, Deborah Bard, Amber Boehnlein, Kjiersten Fagnan, Chin Guok, Eric Lançon, Sreeranjani Ramprakash, Mallikarjun Shankar, Nicholas Schwarz, and Benjamin L. Brown. 2023. Integrated Research Infrastructure Architecture Blueprint Activity (Final Report 2023). (7 20...

    2023 doi

  15. [23]

    2025.Andes User Guide

    OLCF. 2025.Andes User Guide. Retrieved June 27, 2025 from https://docs.olcf. ornl.gov/systems/andes_user_guide.html

    2025

  16. [24]

    2024.OLCF’s Advanced Computing Ecosystem (ACE): FY24 Efforts for the DOE Integrated Research Infrastructure (IRI) Program

    Sarp Oral, Rafael Ferreira Da Silva, Subil Abraham, Ryan Adamson, Valentine Anantharaj, Tom Beck, Ashley Barker, Katie Bethea, Joshua Brown, Michael Brim, et al. 2024.OLCF’s Advanced Computing Ecosystem (ACE): FY24 Efforts for the DOE Integrated Research Infrastructure (IRI) P...

    2024 doi

  17. [25]

    Ramani, K

    S. Ramani, K. Goseva-Popstojanova, and K.S. Trivedi. 2002. A framework for performability modeling of messaging services in distributed systems. InEighth IEEE International Conference on Engineering of Complex Computer Systems, 2002. Proceedings.25–34. doi:10.1109/ICECCS.2002.1181495

    2002 arXiv

  18. [26]

    Anwar Sadat and Gour Karmakar. 2010. A Trade-Off Between Reliability and Energy Efficiency for Inter-cluster Communication in Wireless Sensor Networks. In2010 IEEE 12th International Conference on High Performance Computing and Communications (HPCC). 573–578. doi:10.1109/HPCC.2010.83

    2010 doi

  19. [27]

    Skluzacek, Paul Bryant, A.J

    Tyler J. Skluzacek, Paul Bryant, A.J. Ruckman, Daniel Rosendo, Suzanne Prentice, Michael J. Brim, Ryan Adamson, Sarp Oral, Mallikarjun Shankar, and Rafael Fer- reira da Silva. 2025. Secure API-Driven Research Automation to Accelerate Scientific Discovery. InPractice and Experi...

    2025

  20. [28]

    Pedersen, and Mari Carmen Aguayo- Torres

    Beatriz Soret, Preben Mogensen, Klaus I. Pedersen, and Mari Carmen Aguayo- Torres. 2014. Fundamental tradeoffs among reliability, latency and throughput in cellular networks. In2014 IEEE Globecom Workshops (GC Wkshps). 1391–1396. doi:10.1109/GLOCOMW.2014.7063628

    2014

  21. [29]

    Thayer, Jana, Chen, Zhantao, Claus, Richard, Damiani, Daniel, Ford, Christopher, Dubrovin, Mikhail, Elmir, Victor, Kroeger, Wilko, Li, Xiang, Marchesini, Ste- fano, Mariani, Valerio, Melcchiori, Riccardo, Nelson, Silke, Peck, Ariana, Perazzo, Amedeo, Poitevin, Frederic, O’Grad...

    2024

  22. [30]

    Saint, Ben Blaiszik, Jim Pruyne, Tekin Bicer, Alex Lavens, Zhengchun Liu, Michael E

    Rafael Vescovi, Ryan Chard, Nickolaus D. Saint, Ben Blaiszik, Jim Pruyne, Tekin Bicer, Alex Lavens, Zhengchun Liu, Michael E. Papka, Suresh Narayanan, Nicholas Schwarz, Kyle Chard, and Ian T. Foster. 2022. Linking scientific instru- ments and computation: Patterns, technologie...

    2022

  23. [31]

    Siniša Veseli, John Hammonds, Steven Henke, Hannah Parraga, and Nicholas Schwarz. 2023. Streaming Data from Experimental Facilities to Supercomputers for Real-Time Data Processing. InProceedings of the SC ’23 Workshops of the International Conference on High Performance Comput...

    2023

  24. [32]

    Cong Wang, Valerio Mariani, Frédéric Poitevin, Matthew Avaylon, and Jana Thayer. 2025. End-to-end deep learning pipeline for real-time Bragg peak seg- mentation: from training to large-scale deployment.Frontiers in High Performance ComputingVolume 3 - 2025 (2025). doi:10.3389/...

    2025

  25. [33]

    Xiaoping Wang, Guannan Zhang, Junqi Yin, Siyan Liu, Viktor Reshniak, Zachary Morgan, Sylwia Pawledzio, Thomas Proffen, Huibo Cao, Bryan Chakoumakos, Christina Hoffmann, and Yaohua Liu. 2025. Integrated AI/ML and HPC Frame- work for Multidimensional Neutron Crystallography.Stru...

    2025 doi

  26. [1421]

    arXiv:https://www.science.org/doi/pdf/10.1126/science.adi2336 doi:10.1126/ science.adi2336

    doi

  27. [2022]

    In2022 IEEE International Parallel and Distributed Processing Symposium (IPDPS)

    Coupling streaming ai and hpc ensembles to achieve 100–1000× faster biomolecular simulations. In2022 IEEE International Parallel and Distributed Processing Symposium (IPDPS). IEEE, 806–816

Pith tools

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