A 400Gbit Ethernet core enabling High Data Rate Streaming from FPGAs to Servers and GPUs in Radio Astronomy

Dan Werthimer; Jonathon Kocz; Mitchell C. Burnett; Wei Liu

REVIEW 4 major objections 5 minor 21 references

A 400Gbit Ethernet core enabling High Data Rate Streaming from FPGAs to Servers and GPUs in Radio Astronomy

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

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

Pith's one-line read An open-source 400GbE FPGA core sustains 362 Gbps to two GPUs with zero packet loss.

desk verdict A useful 400GbE FPGA-to-GPU engineering paper with a plausible 362 Gbps result, but the zero-loss claim and single-point measurements need tightening before you trust the headline. read the letter →

arxiv 2411.15630 v1 pith:OOLHMANY submitted 2024-11-23 astro-ph.IM cs.DC

Wei Liu , Mitchell C. Burnett , Dan Werthimer , Jonathon Kocz This is my paper · ORCID

classification astro-ph.IMcs.DC

keywords 400GbEFPGAUDP/IPv4RDMAGPUDirectHASHPIPEradioastronomyGPUstreaming

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 sets out to remove the input/output bottleneck in radio astronomy backends by streaming full 400GbE data from an FPGA into server GPUs. It claims an open-source UDP/IPv4 400GbE core on an AMD Versal FPGA, paired with an RDMA-based receive path, moves 362 Gbps into two GPUs through host DRAM with no packet loss. It also measures alternative paths: GPUDirect moves about 180 Gbps to one GPU and about 90 Gbps per GPU to two GPUs, while two NICs to two GPUs reach about 276 Gbps. If correct, these results mean the data rate from telescopes to GPUs need no longer be the limiting step, shrinking the number of GPUs, servers, power, and cost required for real-time processing.

What carries the argument

The load-bearing pieces are the UDP packet generation core (which builds packets with user-defined MAC, IP, and ports and runs at 390.625 MHz with a 1024-bit DCMAC bus for a nominal 400 Gbps), the MAC/PHY layer built from AMD's DCMAC hard IP and GTM transceivers in half-density mode for 4x106 Gbps lanes, and a receiver based on the HASHPIPE framework using ibverbs RawEth queue pairs for kernel-bypass, zero-copy capture. Packet loss detection uses a 16-bit sequence counter in each packet payload, checked against the received order. The comparison between DRAM staging and GPUDirect identifies the PCIe 4.0 GPU I/O limit of about 200 Gbps as the constraint on direct transfers.

What would settle it

Run the FPGA-to-two-GPU DRAM test for longer than the counter wrap interval (about 12 ms at 362 Gbps with 8192-byte payloads) and confirm TPKTLOSS remains constant, or instrument the test with an independent 32-bit counter or NIC hardware drop counters; any non-recoverable loss in steady state would falsify the zero-loss claim.

Watch

Extended reading notes

Core claim

The central discovery is that a complete FPGA-to-GPU data path can sustain 362 Gbps with zero packet loss, matching the best NIC-to-GPU result through DRAM. The authors built an open-source 400GbE wrapper for the AMD/Xilinx DCMAC and GTM transceivers that generates UDP/IPv4 packets at up to the full 400 Gbps link rate, and combined it with a HASHPIPE-based receiver that stages packets in host DRAM before copying to two GPUs. On the same FPGA-to-GPU path with GPUDirect, the throughput is limited by the PCIe 4.0 GPU interface to about 180 Gbps to one GPU and about 90 Gbps per GPU to two. The paper claims this is the same limit reached in server-to-server tests, indicating the bottleneck is the GPU and PCIe receive side, not the FPGA core.

Load-bearing premise

The zero-packet-loss claim rests on a 16-bit sequence counter and on excluding the initialization period during which the total packet-loss counter is non-zero; if wrap-around handling is flawed or the excluded period hides real drops, the 362 Gbps result could be overstated.

Editorial extensions

If this is right

A single 400GbE link from an FPGA can feed two GPUs at 362 Gbps using host DRAM as staging, so correlators and beamformers can rely on full-rate ingest.
GPUDirect saturates one GPU at about 180 Gbps but does not scale linearly to two GPUs from one NIC; two NICs are needed for about 276 Gbps total.
At 362 Gbps with 8192-byte payloads the 16-bit packet sequence counter wraps roughly every 12 ms, so a robust receiver must handle wrap-around to preserve the zero-loss claim.
The open-source core will be added to the CASPER library, making 400GbE FPGA-to-GPU streaming reusable for other telescope backends and reducing development cost for new instruments.

Reading between the lines

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

If the same receive path were paired with a wider sequence counter or independent NIC hardware counters, the true zero-loss ceiling could be verified without relying on one 16-bit counter and an excluded initialization period.
The DRAM-staging route's advantage over GPUDirect for multiple GPUs suggests that host-memory staging may remain the more scalable ingest pattern for future 800GbE or multi-NIC systems.
Radio arrays with per-antenna rates below 362 Gbps could consolidate an entire backend onto one FPGA plus a few GPUs, a design choice the paper does not explicitly cost out.
The technique likely transfers to other high-throughput scientific instruments wherever UDP streams arrive at servers, such as pulsar search, beamforming, and fast transient detection pipelines.

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.

Desk Editor's Note

read the letter

Jake — quick take. This is a competent engineering paper that hands the radio astronomy community an open-source 400GbE UDP/IPv4 FPGA core and hard numbers for streaming FPGA data into GPUs. The headline 362 Gbps FPGA-to-two-GPUs via DRAM staging is plausible and useful; the GPUDirect comparison is also informative. But the zero-loss claim has a soft foundation: it rests on a 16-bit sequence counter with a known blind spot, and every throughput value is a single-point measurement.

What's actually new: the open-source wrapper for the AMD/Xilinx 400GbE MAC/PHY, the measured end-to-end FPGA-to-GPU rates (362 Gbps to two GPUs via DRAM, ~180 Gbps to one GPU with GPUDirect, ~276 Gbps with two NICs to two GPUs), and a direct comparison of DRAM staging versus GPUDirect. Good practice: they validate GPU PCIe bandwidth with nvbandwidth and memory bandwidth with PCM/stress-ng, so the bottleneck claims are grounded.

Soft spots, in order of concern. The stress-test note is correct: a 16-bit modulo counter cannot see losses of exactly 65536 packets, which at these rates is about 12 ms of traffic. The paper doesn't describe wrap handling, test duration, or trial count, and the TPKTLOSS trace is non-zero during initialization. Section 5 drops the 'after initialization' qualifier and says 'without experiencing any packet loss' unqualified. That's a real overstatement, though likely minor in practice—an outage that long would probably show up elsewhere, but the paper doesn't verify with NIC drop counters or any independent check. Second, no error bars or trial counts on any throughput number. For an engineering measurement paper that's common, but it should be stated. Third, the single-NIC-to-two-GPUs GPUDirect result (~90 Gbps per GPU) is under-explained; 'GPUDirect configuration' is vague.

None of this is load-bearing in the sense that the architecture and roughly 360 Gbps DRAM-staged path are almost certainly sound. The paper is honest about what it measured; it just over-qualifies the loss-free claim. The source isn't public yet, so the 'open-source' claim is promissory, another easy fix.

Who it's for: anyone building FPGA-based radio astronomy backends or comparing 400GbE streaming options. It deserves a serious referee. I'd accept it conditional on the authors releasing the code, adding trials/error bars, describing the counter wrap logic, and rewording the loss claim to steady-state after initialization.

Referee Report

4 major / 5 minor

Summary. The paper describes the development and testing of an open-source UDP/IPv4 400GbE FPGA core (based on AMD/Xilinx Versal hardware) for streaming data from FPGAs to servers and GPUs in radio astronomy. The authors benchmark two receive-side data paths: RDMA through host DRAM to two GPUs, and GPUDirect RDMA to one or two GPUs. They report that the DRAM-staged path sustains approximately 360 Gbps (362 Gbps in the FPGA-to-GPU configuration) without packet loss, while GPUDirect achieves about 180 Gbps to one GPU and about 90 Gbps per GPU to two GPUs. The paper also reports memory and PCIe bandwidth verification using standard tools, and it makes the core and associated software available as open source for the CASPER library.

Significance. If the reported performance holds, the open-source 400GbE core and the DRAM-staged receive path are a useful contribution to the CASPER ecosystem and to radio-astronomy backend design, potentially reducing the number of GPUs and servers required for real-time processing. The paper includes several good practices: cross-checking GPU PCIe bandwidth with NVIDIA's nvbandwidth, verifying memory bandwidth with Intel PCM and stress-ng, and providing public code repositories. The measurements are internally consistent, and I found no fitted parameters or circular derivations. However, the central zero-packet-loss claim is currently overstated: the paper's own diagnostic (TPKTLOSS) shows non-zero loss during initialization, and the 16-bit sequence counter is blind to certain loss patterns. These issues are fixable, so the contribution remains valuable, but the manuscript needs revision before the central claim is reliable.

major comments (4)

[Section 4.2 / Figure 23 / Section 5] The unqualified claim that 'data rates of 362 Gbps were transferred without experiencing any packet loss' is not supported by the paper's own evidence. Figure 23's caption explicitly states that TPKTLOSS is non-zero during initialization and only becomes constant afterward, so the measured result is 'no loss in steady state after initialization,' not 'no loss during the entire transfer.' In addition, the 16-bit per-packet sequence counter cannot detect losses that are exact multiples of 65536 packets: if l packets are lost, the receiver-observed delta equals 1 whenever l mod 65536 = 0. At 362 Gbps with 8192-byte payloads, 65536 packets correspond to roughly 11.9 ms of traffic, so a complete outage of that duration or any multiple would be invisible to the loss check. The paper does not describe the receiver's wrap-around handling, the test duration, the number of trials, or any independent loss verification such as NIC hardware drop counters. The zero-loss conclusion therefore rests on an insecure measurement assumption and should be re-stated as 'no detected loss in the steady-state interval' with the counter width, wrap handling, and test duration reported.
[Section 3.2 / Figure 9] The same initialization-period issue applies to the NIC-to-DRAM-to-GPU test that reports 'about 360 Gbps without packet loss.' The caption of Figure 9 states that TPKTLOSS is non-zero during initialization, so the reported zero-loss condition again refers only to steady state. The paper should quantify the number of packets lost during initialization, specify when the steady-state measurement begins, and explain whether those initialization losses are inherent to the test setup or to the receive framework. Without this information, the reader cannot distinguish a genuine steady-state capability from a measurement that simply excludes losses from the reported interval.
[Sections 3.3–3.5 and 4.3] All throughput values are single-point measurements: the paper reports '178 Gbps', '~90 Gbps × 2', '~138 Gbps × 2', and '~180 Gbps' without error bars, trial counts, or any indication of run-to-run variance. This is especially important in Section 3.5, where the difference between the single-NIC GPUDirect result (~180 Gbps total) and the dual-NIC result (~276 Gbps total) is attributed to 'GPUDirect configuration and PCIe lanes available in the case of a single NIC.' That attribution is speculative without repeated measurements or a direct comparison of the PCIe topology, and the current single-point data do not allow the reader to assess whether the difference is significant. The paper should report the number of trials, the mean and spread of each rate, and the conditions under which each maximum was obtained.
[Section 4.2] The sentence 'This result is identical as we obtained in Section 3.2' is imprecise and potentially misleading. Section 3.2 reports ~360 Gbps for the NIC-to-DRAM-to-GPU path, while Section 4.2 reports ~362 Gbps for the FPGA-to-NIC-to-DRAM-to-GPU path, and the two tests use different packet generators and different transmission sources. If the ~362 Gbps limit is set by the server-side receive path or by the HASHPIPE framework rather than by the FPGA core, the paper should state this explicitly; as written, the claim of identity obscures whether the bottleneck is the FPGA transmitter or the receiving system.

minor comments (5)

[Section 4.3] There is a typo in 'differet steer flows' (should be 'different').
[Tables 1 and 2] The tables have broken formatting: 'T able 1' and 'V ersion' appear with stray spaces, and Table 2 lists bandwidth in GB/s while the surrounding text uses Gbps. The authors should ensure consistent units and correct table rendering.
[Section 2.2] The text states that PCIe 4.0 limits throughput to 200 Gbps, but Table 2 lists PCIe 4.0 x16 unidirectional bandwidth as 31.5 GB/s, which is 252 Gbps. The paper should reconcile this discrepancy and clarify whether the 200 Gbps figure refers to the effective payload bandwidth observed on the GPUs.
[Figure 25 caption] The caption reads 'GPUDirect from FPGA to NIC results,' but the described test is from FPGA through the NIC to GPUs; the caption should be corrected to avoid confusion about the data path.
[Section 4.2] The paper does not state the packet payload size used in the FPGA-to-GPU test; Section 3.3 mentions 8192-byte payloads for the server-to-server test, but it is not clear whether the same size was used in the FPGA tests. Reporting the packet size is necessary for reproducing the loss-detection wrap calculation and for interpreting the achieved line-rate fraction.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the throughput and loss results are measured end-to-end against independent hardware counters and sequence checks, not derived from fitted inputs or self-citations.

full rationale

This paper is an experimental hardware evaluation with no fitted parameters, no derivation chain, and no predictive model whose output is built from its own inputs. The central results—362 Gbps through DRAM staging, ~180 Gbps per GPU with GPUDirect, and the FPGA-to-GPU rates—are measured quantities obtained by sending packets with sequence counters and comparing sent versus received counts. The paper's use of the CASPER 100G core as a starting point for the 400GbE core is an engineering reuse, not a load-bearing self-citation: the 400GbE core's reported performance is verified by the server-side NIC state, the HASHPIPE status buffer, and the ibverbs completion counters, all external to the paper's own assumptions. The authors' references to their own repositories provide the test code but do not define the measured outcomes. Sections 3.2, 3.3, 4.2, and 4.3 describe direct measurements of packet loss and throughput in a live link, and the paper explicitly reports limitations such as non-zero TPKTLOSS during initialization and PCIe 4.0 bottlenecks. Any concern about the 16-bit sequence counter's inability to detect losses that are exact multiples of 65536 packets, or about the exclusion of the initialization period, is a measurement-validity critique, not a circularity: the claim is not forced by the paper's definitions or by a fitted parameter renamed as a prediction. Per the review rules, such correctness concerns belong outside the circularity score, and no circular step can be exhibited by quoting an equation that reduces to itself. The honest finding is therefore no significant circularity, score 0.

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

The central claims rest on the reliable operation of AMD/Xilinx DCMAC and GTM IP, on representative PCIe and memory bandwidth measurements, and on the correctness of the HASHPIPE packet-loss detection. No free parameters are fitted, and no new entities are postulated.

assumptions (3)

domain assumption AMD/Xilinx DCMAC hard IP and GTM transceivers implement IEEE 802.3ck-2022 400GBASE-CR4 correctly as configured.
Section 4.1.2 relies on these IP blocks for PCS/PMA; no independent verification of spec compliance beyond the NIC reporting link-up at 400G.
domain assumption The measured PCIe and memory bandwidths are representative of the system limits used to interpret the streaming results.
Sections 2.2 and 2.3 use these measurements to claim that GPUs and memory are the bottlenecks.
domain assumption The HASHPIPE software correctly counts packets and the 16-bit counter with wrap handling detects all losses.
Sections 3.2 and 4.2 rely on this for the zero-packet-loss conclusion; the counter wrap and excluded initialization period are not fully analyzed.

how reviews work

0 comments

Cite this review

Pith. "Pith review of A 400Gbit Ethernet core enabling High Data Rate Streaming from FPGAs to Servers and GPUs in Radio Astronomy." pith.science (2026). https://pith.science/paper/OOLHMANY

@misc{pith2026241115630,
  author       = {Pith},
  title        = {Pith review of: A 400Gbit Ethernet core enabling High Data Rate Streaming from FPGAs to Servers and GPUs in Radio Astronomy},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/OOLHMANY}},
  note         = {Machine review of arXiv:2411.15630}
}

read the original abstract

The increased bandwidth coupled with the large numbers of antennas of several new radio telescope arrays has resulted in an exponential increase in the amount of data that needs to be recorded and processed. In many cases, it is necessary to process this data in real time, as the raw data volumes are too high to be recorded and stored. Due to the ability of graphics processing units (GPUs) to process data in parallel, GPUs are increasingly used for data-intensive tasks. In most radio astronomy digital instrumentation (e.g. correlators for spectral imaging, beamforming, pulsar, fast radio burst and SETI searching), the processing power of modern GPUs is limited by the input/output data rate, not by the GPU's computation ability. Techniques for streaming ultra-high-rate data to GPUs, such as those described in this paper, reduce the number of GPUs and servers needed, and make significant reductions in the cost, power consumption, size, and complexity of GPU based radio astronomy backends. In this research, we developed and tested several different techniques to stream data from network interface cards (NICs) to GPUs. We also developed an open-source UDP/IPv4 400GbE wrapper for the AMD/Xilinx IP demonstrating high-speed data stream transfer from a field programmable gate array (FPGA) to GPU.

Figures

Figures reproduced from arXiv: 2411.15630 by the authors.

**Figure 1.** Diagram of a typical radio astronomy system showing the flow of data from telescopes to data processing centers. NICs, FPGAs, and GPUs are required to manage high-speed data streams. Modern GPUs are powerful enough for most radio astronomy data processing applications. However, moving data between different system components, such as FPGAs to NICs to GPUs is often a limiting step in the data processing pipeline. Uti… view at source ↗

**Figure 2.** The server we setup for the 400G test, which includes 2 x RTX A6000(RTX 4070) GPUs, a 400G NIC, 8 x DDR5 DIMMs, a PCIe5.0 mother board and a PCIe5.0 CPU. PCIe Version Release Year Transfer Rate (GT/s per lane) Bandwidth (GB/s per lane) Unidirectional Bandwidth (x16 configuration, GB/s) 1.0 2003 2.5 0.250 4.0 2.0 2007 5.0 0.500 8.0 3.0 2010 8.0 0.985 15.75 4.0 2017 16.0 1.969 31.5 5.0 2019 32.0 3.938 63.0 6.0 2022 64… view at source ↗

**Figure 3.** Measured bandwidth performance of the RTX A6000 and RTX 4070 GPUs over a PCIe 4.0 interface. The results indicate a maximum achievable bandwidth of ∼200 Gbps. 2.3. Memory Bandwidth High-speed data transfer also depends on memory bandwidth, which in this case must have a minimum capacity of 400 Gbps in order to accommodate simultaneous 400 Gbps data streams. With eight DDR5 DIMMs operating at 4800 MHz and an eight DD… view at source ↗

Figures from the paper (22 more)

**Figure 4.** Figure 4: Memory bandwidth measurement of an 8-channel DDR5 memory configuration using the Intel Performance Counter Monitor (PCM) tool and stress-ng. The total memory bandwidth achieved is approximately ∼1013 Gbps, meeting the requirements for 400 Gbps data transfer [PITH_FULL…

**Figure 5.** Figure 5: Setup of the 400G test servers used in the experiment. The servers are equipped with 400G NICs and GPUs to evaluate data transfer performance using various techniques. Ibverbs (InfiniBand Verbs) is a low-level programming interface specifically made for InfiniBand/RDMA…

**Figure 6.** Figure 6: Comparison of data transfer processes using UDP and RDMA. The figure highlights the benefits of RDMA, including zero-copy and kernel bypass, which result in higher throughput and lower latency. by ibverbs is RawEth, which captures UDP packets via kernel bypass and zero…

**Figure 7.** Figure 7: Data transfer path from NIC to GPUs via DRAM. This method utilizes the available memory bandwidth to handle high-speed data streams. Red dashed lines show the direction of data transfer. In order to estimate the efficiency of data transfer from a NIC to GPUs via DRAM, …

**Figure 8.** Figure 8: Architecture of the HASHPIPE framework used in the data transfer tests. The framework provides separate network and GPU threads for efficient packet handling, as well as provides real-time thread status monitoring. The ibverbs APIs are used in the network thread and al…

**Figure 9.** Figure 9: Measured bandwidth performance of the RTX A6000 and RTX 4070 GPUs during the NIC to GPUs via DRAM test. Results show that the data transfer rate without packet loss is about 360 Gbps. RPKTLOSS shows the real-time packet loss, which is always zero after the initializati…

**Figure 10.** Figure 10: Direct data transfer path from NIC to GPU using GPUDirect technology. RDMA transactions reduces latency by bypassing the CPU and system memory. The link between the two servers is 200G. Red dashed lines shows the direction of data transfer.) Packets on the transmitter…

**Figure 11.** Figure 11: Measured bandwidth results of data transfers using GPUDirect to a single GPU on a 200 Gbps link. The maximum data rate achieved without packet loss is 178 Gbps. The packet loss is checked By comparing the number of sent packets and received packets. In each test, 1638…

**Figure 12.** Figure 12: Direct data transfer path from NIC to two GPUs using GPUDirect technology. The link between the two servers is 400G link. Red dashed lines show the direction of data transfer. On the transmitter server side, the same code based on ibverbs API mentioned in section 3.3 …

**Figure 13.** Figure 13: Measured bandwidth results of data transfers to two GPUs using GPUDirect on a 400Gbps link. The maximum data rate achieved is ∼90Gbps × 2 [PITH_FULL_IMAGE:figures/full_fig_p010_13.png]

**Figure 14.** Figure 14: Direct data transfer path from two NIC to two GPUs on one server. Both of the two NICs send data to each other, and use GPUDirect to move the received data to two GPUs. The link is 200G. Red and blue dashed lines shows the direction of data transfer [PITH_FULL_IMAGE:…

**Figure 15.** Figure 15: Measured bandwidth results of data transfers from two NICs to two GPUs using GPUDirect on a 200Gbps(× 2) link. The maximum data rate achieved is ∼138Gbps × 2 [PITH_FULL_IMAGE:figures/full_fig_p011_15.png]

**Figure 16.** Figure 16: Block diagram of the 400GbE FPGA core shows the UDP packet generation and MAC/PHY core modules. 4.1. 400GbE Core Implementation 4.1.1. UDP packet generation core The 400GbE UDP generation core, modified from the CASPER 100G core17, consists of two submodules: a stream…

**Figure 17.** Figure 17: Block diagram of the streaming data module within the 400GbE FPGA core. The module handles high-speed data transmission and reception, including packet generation and filtering. 17 https://github.com/casper-astro/kutleng skarab2 bsp firmware [PITH_FULL_IMAGE:figures/…

**Figure 18.** Figure 18: Integrated DCMAC core and GTM transceivers in the 400GbE MAC/PHY core. The components work together to support high-speed Ethernet communication [PITH_FULL_IMAGE:figures/full_fig_p013_18.png]

**Figure 19.** Figure 19: Complete architecture of the 400GbE FPGA core, illustrating the integration of various modules to achieve 400Gbps data transfer rates. 4.2. FPGA to NIC to GPU through DRAM result To evaluate bandwidth performance of the 400GbE FPGA core, we developed a packet generati…

**Figure 20.** Figure 20: Diagram showing the setup for the FPGA to NIC to GPU via DRAM data transfer test. The setup includes the FPGA board, 400G NIC, and GPUs to evaluate data transfer performance. Before further testing, we confirmed the 400G link between the FPGA and the server with a 400…

**Figure 21.** Figure 21: The actual setup used for the FPGA to NIC to GPU test. The setup demonstrates the hardware configuration and connections used in the experiment [PITH_FULL_IMAGE:figures/full_fig_p015_21.png]

**Figure 22.** Figure 22: Status indication of the FPGA linked to the 400G NIC at a 400 Gbps data rate. The figure confirms the active state and link speed of the connection. (a) RTX A6000 FPGA to GPU bandwidth performance (b) RTX 4070 FPGA to GPU bandwidth performance [PITH_FULL_IMAGE:figure…

**Figure 23.** Figure 23: Test results of the FPGA to NIC to two GPUs data transfer, showing a data rate of 362Gbps without packet loss. RPKTLOSS shows the real-time packet loss, which is always zero after the initialization; TPKTLOSS shows the total number of packet loss, which is non-zero du…

**Figure 24.** Figure 24: FPGA and server are connected with 400G link. FPGA sends out two kinds of packets with different source and dest port numbers: Packet-A and Packet-B. The data stream are steered to two queue pairs with different steer flow, and then sent to two GPUs directly. If only …

**Figure 25.** Figure 25: GPUDirect from FPGA to NIC results. If one queue pair is enabled on the receiver side, the bandwidth is about ∼180Gbps; if both of the two queue pairs are enabled, bandwidth for each data stream is ∼90Gbps, and total is about ∼180Gbps [PITH_FULL_IMAGE:figures/full_fi…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

21 extracted references · 19 canonical work pages

[1]

2021, IEEE Access, 9, 18167

Ad´ amek, K., Novotn` y, J., Thiyagalingam, J., & Armour, W. 2021, IEEE Access, 9, 18167

work page 2021
[2]

2020, Monthly Notices of the Royal Astronomical Society, 497, 352

Agarwal, D., Lorimer, D., Surnis, M., et al. 2020, Monthly Notices of the Royal Astronomical Society, 497, 352

work page 2020
[3]

2017, Astronomy and computing, 18, 35

Akeret, J., Chang, C., Lucchi, A., & Refregier, A. 2017, Astronomy and computing, 18, 35

work page 2017
[4]

2016, in

Alvear, A., Finger, R., Fuentes, R., et al. 2016, in

work page 2016
[5]

2022, Univ

Ayala, A., Tomov, S., Luszczek, P., et al. 2022, Univ. Tennessee at Knoxville, Knoxville, TN, USA, Tech. Rep. ICL-UT-22–02

work page 2022
[6]

L., Wild, W., & Cunningham, C

Brown, R. L., Wild, W., & Cunningham, C. 2004, Advances in Space Research, 34, 555

work page 2004
[7]

2000, Implementation, and Signal Processing, NRC-EVLA Memo, 1

Carlson, B. 2000, Implementation, and Signal Processing, NRC-EVLA Memo, 1

work page 2000
[8]

A., Plante, P

Clark, M. A., Plante, P. L., & Greenhill, L. J. 2013, The International journal of high performance computing applications, 27, 178

work page 2013

Show all 21 references

[9]

L., Ravi, V., & Hallinan, G

Connor, L., Bouman, K. L., Ravi, V., & Hallinan, G. 2022, Monthly Notices of the Royal Astronomical Society, 514, 2614

2022
[10]

E., Hall, P

Dewdney, P. E., Hall, P. J., Schilizzi, R. T., & Lazio, T. J. L. 2009, Proceedings of the IEEE, 97, 1482

2009
[11]

2019, arXiv preprint arXiv:1907.07648

Hallinan, G., Ravi, V., Weinreb, S., et al. 2019, arXiv preprint arXiv:1907.07648

2019 arXiv
[12]

2016, Journal of Astronomical Instrumentation, 5, 1641001

Hickish, J., Abdurashidova, Z., Ali, Z., et al. 2016, Journal of Astronomical Instrumentation, 5, 1641001

2016
[13]

2020, Publications of the Astronomical Society of the Pacific, 132, 085001

Jiang, H., Yu, C.-Y., Chen, M., & Liu, M. 2020, Publications of the Astronomical Society of the Pacific, 132, 085001

2020
[14]

2016, in MeerKAT Science: On the Pathway to the SKA, 1, doi: 10.22323/1.277.0001

Jonas, J., & MeerKAT Team. 2016, in MeerKAT Science: On the Pathway to the SKA, 1, doi: 10.22323/1.277.0001

2016 doi
[15]

Kalia, A., Kaminsky, M., & Andersen, D. G. 2016, in 2016 USENIX Annual Technical Conference (USENIX ATC 16), 437–450

2016
[16]

L., Chen, J., et al

Li, A., Song, S. L., Chen, J., et al. 2019, IEEE Transactions on Parallel and Distributed Systems, 31, 94

2019
[17]

2021, Journal of Instrumentation, 16, P08047

Liu, W., Meng, Q., Wang, C., et al. 2021, Journal of Instrumentation, 16, P08047

2021
[18]

H., Price, D

MacMahon, D. H., Price, D. C., Lebofsky, M., et al. 2018, Publications of the Astronomical Society of the Pacific, 130, 044502

2018
[19]

Romein, J. W. 2021, Astronomy & Astrophysics, 656, A52 18

2021
[20]

2007, SKA Memorandum, 100

Schilizzi, R., Alexander, P., Cordes, J., et al. 2007, SKA Memorandum, 100

2007
[21]

2024, Research in Astronomy and Astrophysics

Yu, Z., Deng, F., Sun, S., et al. 2024, Research in Astronomy and Astrophysics

2024

Pith tools

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

[1] [1]

2021, IEEE Access, 9, 18167

Ad´ amek, K., Novotn` y, J., Thiyagalingam, J., & Armour, W. 2021, IEEE Access, 9, 18167

work page 2021

[2] [2]

2020, Monthly Notices of the Royal Astronomical Society, 497, 352

Agarwal, D., Lorimer, D., Surnis, M., et al. 2020, Monthly Notices of the Royal Astronomical Society, 497, 352

work page 2020

[3] [3]

2017, Astronomy and computing, 18, 35

Akeret, J., Chang, C., Lucchi, A., & Refregier, A. 2017, Astronomy and computing, 18, 35

work page 2017

[4] [4]

2016, in

Alvear, A., Finger, R., Fuentes, R., et al. 2016, in

work page 2016

[5] [5]

2022, Univ

Ayala, A., Tomov, S., Luszczek, P., et al. 2022, Univ. Tennessee at Knoxville, Knoxville, TN, USA, Tech. Rep. ICL-UT-22–02

work page 2022

[6] [6]

L., Wild, W., & Cunningham, C

Brown, R. L., Wild, W., & Cunningham, C. 2004, Advances in Space Research, 34, 555

work page 2004

[7] [7]

2000, Implementation, and Signal Processing, NRC-EVLA Memo, 1

Carlson, B. 2000, Implementation, and Signal Processing, NRC-EVLA Memo, 1

work page 2000

[8] [8]

A., Plante, P

Clark, M. A., Plante, P. L., & Greenhill, L. J. 2013, The International journal of high performance computing applications, 27, 178

work page 2013