Benchmarking Tools
Relevant source files
The following files were used as context for generating this wiki page:
Introduction
The gr-cuda project includes a suite of benchmarking tools designed to evaluate the performance of GPU-accelerated signal processing blocks. These tools measure key metrics such as throughput in Giga-samples per second (Gsps), transfer rates in GB/s, and computational efficiency across various engines including cuFFT (C++), CuPy (Python), and FFTW (CPU).
The primary focus of these tools is to validate the Zero-copy GPU pipeline and the effectiveness of the cuda_buffer implementation, which handles host-device transfers and CUDA-event synchronization. By isolating compute performance from PCIe overhead and testing parallel data chains, the benchmarking suite provides a comprehensive view of the system's performance limits.
Sources: README.md:10-20, apps/benchmark_gr_cuda_fft.py:12-18
Core Benchmarking Applications
FFT Throughput Benchmarking
The benchmark_gr_cuda_fft.py script compares the throughput of different FFT engines. It supports cufft (GPU C++), cupy (GPU Python), and cpu (FFTW). To isolate compute performance, GPU benchmarks run entirely on-device using a GPU-native null_source and null_sink, avoiding PCIe bottlenecks.
The following flowchart illustrates the data flow for an on-device FFT benchmark:
The diagram shows how the benchmark minimizes host interaction by keeping the data chain within the GPU memory space.
Sources: apps/benchmark_gr_cuda_fft.py:53-73, apps/benchmark_gr_cuda_fft.py:112-120
Transfer Rate Benchmarking
The benchmark_gr_cuda_transfer.py script measures the efficiency of the cuda_buffer pipeline. It evaluates three primary modes:
- Host-to-Device (H2D): CPU source to GPU sink.
- Device-to-Host (D2H): GPU source to CPU sink.
- Full Round-trip: CPU source to GPU processing back to CPU sink.
Large output_multiple settings are utilized to force the GNU Radio scheduler to issue large work calls, which is critical for maximizing PCIe throughput.
Sources: apps/benchmark_gr_cuda_transfer.py:34-60, apps/benchmark_gr_cuda_transfer.py:72-76
Performance Stress Testing
The qa_long_race_stress.py utility provides long-duration stress testing (e.g., 3600 seconds) to detect race conditions or buffer synchronization issues. It employs a "fan-in/fan-out" architecture where data passes through multiple parallel GPU chains before being aggregated and verified on the CPU.
Sources: python/cuda/qa_long_race_stress.py:65-80
Benchmark Configuration and Metrics
Execution Parameters
Benchmarking scripts share common configuration patterns to ensure measurement accuracy, including warmup periods and automated buffer scaling.
| Parameter | Default | Description |
|---|---|---|
duration | 10.0s | Active measurement time per configuration. |
warmup | 1.0s | Time allowed for the pipeline to reach steady state before counting. |
WORK_BATCH_BYTES | 64 MiB | Target data size per work() call to ensure fair comparison. |
BUFFER_MULTIPLE | 16-32 | Multiplier for output_multiple to provide buffer headroom. |
Sources: apps/benchmark_gr_cuda_fft.py:42-43, apps/benchmark_gr_cuda_fft.py:130-145, apps/benchmark_gr_cuda_transfer.py:27, apps/benchmark_gr_cuda_transfer.py:115-125
Calculation Logic
Metrics are derived from the number of items processed by the "meter" block (usually the sink) over the measured duration.
# From apps/benchmark_gr_cuda_fft.py:120-125
elapsed = t1 - t0
total_vectors = n1 - n0
ffts_per_sec = total_vectors / elapsed
gsps = (total_vectors * fft_size) / elapsed / 1e9
Sources: apps/benchmark_gr_cuda_fft.py:120-125, apps/benchmark_gr_cuda_transfer.py:100-105
Sequence of Benchmark Execution
The typical lifecycle of a benchmark run involves block construction, steady-state warmup, and differential counter sampling.
The diagram outlines the synchronization between the Python control script and the underlying GNU Radio scheduler during a measurement cycle.
Sources: apps/benchmark_gr_cuda_fft.py:107-120, apps/benchmark_gr_cuda_transfer.py:91-105
Conclusion
The benchmarking tools in gr-cuda provide essential data for optimizing GPU-accelerated signal processing. By leveraging both high-level Python scripts for throughput analysis and low-level stress tests for race condition detection, developers can ensure that the zero-copy pipeline maintains high performance without sacrificing data integrity.
Sources: README.md:65-75, apps/benchmark_gr_cuda_transfer.py:183-186