Double-pipeline cooperation and backpressure control method and device for multi-card PCIe acquisition system

Abstract

The invention relates to the technical field of electronic information and software engineering, in particular to a double-pipeline cooperation and backpressure control method for a multi-card PCIe acquisition system. The method comprises a data acquisition pipeline and a control / monitoring pipeline, the data acquisition pipeline executes sampling, DMA carrying and frequency spectrum / time domain updating, and the control / monitoring pipeline executes state sampling and prompt event generation based on a backpressure index and drives a front-end interface to perform linkage display through an asynchronous signal. According to the method, the system data loss rate and the interface refreshing delay are remarkably reduced, and the operation response speed and the system operation and maintenance performance are improved.

Description

Technical Field

[0001] This invention belongs to the field of electronic information and software engineering technology, specifically relating to a back pressure monitoring and front-end linkage control method and device in a multi-card PCIe acquisition system, targeting terahertz source signal systems and related high-throughput real-time visualization scenarios. Background Technology

[0002] Nuclear fusion, as the ultimate energy source, has been incorporated into my country's three-step strategic path of "thermal reactor—fast reactor—fusion reactor." During device operation, optical path detection and real-time closed-loop control of plasma parameters are crucial for maintaining energy confinement and safety boundaries. Related systems generally require high-throughput acquisition, low-latency links, stable visualization, and reliable operational guidance. Under conditions of multi-card concurrency and high-speed throughput, buffer levels and link backpressure fluctuate rapidly. Without visibility and handling mechanisms, data loss and response delays are likely to occur. Terahertz source signal systems have wide applicability in industrial detection, intelligent transportation, biomedicine, environmental monitoring, and scientific research and teaching. In engineering, high-throughput acquisition and real-time visualization are needed to support operators in observing and handling key parameters, and backpressure monitoring and front-end prompts should reduce observation and response delays under sudden loads. Traditional implementations often involve shared-thread or shared-lock execution of common status monitoring and acquisition updates, and shared-lock and long-term synchronization waiting for front-end prompts and rendering. Furthermore, the lack of a unified time base and hierarchical threshold management leads to invisible backpressure, delayed prompts, interface lag, and untimely handling. Based on the above issues, there is an urgent need to obtain backpressure visibility and front-end linkage prompts through a lightweight software mechanism without modifying the hardware and drivers, to ensure the continuity of the acquisition link by adopting a non-blocking and asynchronous connectivity strategy, and to adapt to different loads and scenarios through configurable parameters. Summary of the Invention

[0003] This invention proposes a method and apparatus for "dual-pipeline collaboration and backpressure linkage," which separates data acquisition and control / monitoring at the architectural level and decouples them through asynchronous signal connections. This achieves low-latency front-end prompts and visual linkage using a non-blocking strategy. Without modifying the hardware or existing acquisition links, it improves stability, visibility, and response efficiency under multi-card concurrent conditions.

[0004] Its key points include the following: architecture separation: the acquisition pipeline is responsible for sampling, buffer management, and frequency / time domain updates; the control / monitoring pipeline is responsible for status reception, periodic sampling, and early warning prompts;

[0005] Asynchronous decoupling: Connect modules with signals / slots or message queues to avoid cross-thread blocking and resource contention;

[0006] Periodic sampling: The timer driver reads the FIFO fill rate and overflow event, generates a prompt event in a separate path, and records it in the log.

[0007] Front-end linkage: The acquisition and update of signals drives the window to refresh, and the prompt information is displayed on the same screen as the spectrum / time domain, providing operation guidance;

[0008] Configurable parameters: Sampling period, threshold stratification, alert level, log frequency limit and refresh rate can be configured to adapt to different loads;

[0009] Comparison and Improvements with Existing Technologies: Existing status monitoring solutions suffer from two major bottlenecks: First, data acquisition and interface updates are executed in the same thread and use shared lock mechanisms, leading to cross-thread blocking and interface lag; second, the prompting system lacks a unified time base and hierarchical thresholds, causing delays in processing. To overcome these challenges, this invention restructures the data processing-related parts of the software architecture: First, a dual-pipeline separation design is adopted to achieve asynchronous, non-blocking processing of data acquisition and prompts; second, a unified time base and hierarchical threshold system are established to ensure the timeliness and accuracy of prompts.

[0010] This solution addresses the issues of high data loss rate and large interface refresh latency at the software level, significantly improving response speed and processing efficiency, and can be flexibly deployed in various scenarios without hardware modifications. Attached Figure Description

[0011] Figure 1 This provides an overview of the system architecture, specifically the dual-pipeline architecture.

[0012] Figure 2 For back pressure alerts and event / log processes.

[0013] Figure 3 This relates to thread priority and state transitions. Detailed Implementation

[0014] This implementation reduces data loss rate and interface refresh latency in high-load scenarios, improving prompt response time and operator efficiency. Through dual-pipeline separation and non-blocking strategies, it ensures that the data acquisition link is not blocked by prompts and monitoring processes. It adopts a unified time base and threshold layering to support level prompts and review analysis, while maintaining good scalability and low migration costs without modifying hardware and drivers.

[0015] The terminology used in this document follows these conventions: Back pressure indicators refer to the path pressure signals provided by the device / protocol layer, including at least FIFO fill rate and overflow events; Alert events refer to front-end display entities generated by status checks or device events, including card index, indicator value or event type, timestamp, and alert level; Acquisition pipelines are responsible for sampling, buffer management, and frequency / time domain updates; Control / monitoring pipelines are responsible for status reception, periodic sampling, and early warning alerts; Asynchronous signal connection refers to a mechanism for module communication using signals / slots or message queues; Non-blocking strategy refers to a processing method that does not introduce cross-thread waiting or long-term synchronization; Time base refers to using a monotonic clock to uniformly record event timestamps; Threshold stratification refers to dividing indicators into normal, early warning, and important alert ranges, using levels to drive display and handling. Abbreviations: THz (terahertz), FFT (Fast Fourier Transform), DMA (Direct Memory Access), FIFO (First-In-First-Out Buffer), UI (User Interface), and KPI (Key Performance Indicator) are used according to industry-standard definitions.

[0016] System Architecture and Module Division: This system adopts a dual-pipeline architecture, with a data acquisition pipeline and a control / monitoring pipeline set up under the overall main control. The former is responsible for sampling, buffer management, data replication, and spectrum / time domain updates, while the latter is responsible for status signal reception, periodic sampling, early warning processing, and front-end prompts. Around these two pipelines, the module responsibilities are clearly divided into device protocols and status interfaces, acquisition threads and their buffers, front-end control objects and signal windows (responsible for frequency / time domain rendering), and unified configuration and operation management. The modules are asynchronously decoupled using a message / signal mechanism to avoid cross-thread blocking and resource contention, ensuring continuous acquisition and smooth display even under multi-GPU concurrency conditions.

[0017] Initialization and Device Enumeration: During the startup phase, the system sequentially completes device enumeration, object creation, pipeline establishment, and thread registration and priority setting. In multi-card concurrent scenarios, registration and alignment are completed based on card index or bus order to ensure a one-to-one correspondence between data paths and state paths. Acquisition-related threads are configured with higher priority from initialization to ensure the continuity of DMA and data transfer, while monitoring and front-end updates are accessed through asynchronous callbacks and frequency limiting mechanisms to reduce interference with the main acquisition path.

[0018] Data acquisition pipeline (sampling → copying → updating): The acquisition thread acquires data from the device channel using DMA and writes it to the buffer (preferably a circular buffer). Lightweight copying is performed when necessary to isolate front-end read / write operations. Once data is ready, the front-end control object is notified via asynchronous signals (signals / slots or message queues), which then pushes it to the signal window to complete frequency / time domain rendering. The rendering phase employs on-demand refresh, region update, and batch merging strategies to reduce rendering overhead. To ensure continuous acquisition, the acquisition path is decoupled from the monitoring / notification process, cross-thread communication uses a non-blocking mechanism, and acquisition-related threads are set to high or real-time priority. Under extreme load, the refresh rate is automatically reduced and rendering batches are merged to maintain throughput.

[0019] Control / Monitoring Pipeline (Indicator → Sampling → Alert): The monitoring path runs independently of the acquisition thread, periodically reading the FIFO fill rate from the protocol layer and listening for overflow events. The sampling is driven by timers or hardware events. Each sampling uses a non-blocking method, generating only lightweight events with timestamps, threshold judgments, and level markers. When the fill rate enters a high-occupancy range or overflow occurs, the master controller generates a user prompt at the alert processing entry point and writes it to the log; when the indicator recovers below the threshold, the prompt is automatically canceled and the recovery event is recorded. Because monitoring and alerts are decoupled from the acquisition path, backpressure alerts do not interrupt sampling and DMA transfer; in high-load scenarios, the sampling period can be adaptively relaxed to reduce the impact on system resources while preserving the immediacy of critical events.

[0020] Data and Time Base Management: The system uniformly attaches a monotonic clock timestamp to all events and alerts for subsequent tracking and review. Events are encapsulated using a lightweight structure or record body, carrying a card index, indicator value or event type, alert level, and necessary descriptive fields. Data updates and alert displays maintain a consistent view across the time dimension, helping operators to quickly assess and intervene in a timely manner, avoiding misjudgments caused by inconsistent time bases across modules.

[0021] Backpressure metrics and alert strategies: This system treats the FIFO fill rate as a direct measure of buffer occupancy and overflow events as a strong indicator of data loss risk. During operation, alerts and handling are tiered based on thresholds: no alerts are generated when the fill rate is in the normal range (e.g., below 70%); a moderate alert is generated when it enters the high occupancy range (e.g., 70% to 90%); once a higher threshold is crossed or an overflow event is detected, a critical alert is triggered and the event is fully logged. Alerts are highlighted in the status bar, displayed simultaneously in the text area and logs. The thresholds and alert levels can be adjusted in the configuration according to different scenarios to adapt to different load intensities and visualization needs.

[0022] Event Model and Logging: The system uniformly defines three types of events: alerts, overflows, and recovery. Each record includes a timestamp, card index, key indicator or event code, alert level, and possible handling actions. Events can be output to the console, file, and debug window simultaneously. Log writing uses an asynchronous queue to avoid blocking the acquisition and rendering threads. The monitoring thread samples at fixed or adaptive intervals, while the front-end refresh is subject to a maximum frame rate limit. This creates a controllable, traceable, and high-throughput-tolerance collaborative mechanism between alerts, graphics updates, and event writing.

[0023] Front-end Integration and Interface Standards: The front-end interface employs a tiered prompting strategy, classifying prompts into general and important levels. High-load prompts provide the reason, suggested actions, and expected impact, facilitating quick decision-making by operators. The status bar and log area are synchronized, and the status bar is allowed to flash or be highlighted when overflow occurs. Under extreme loads, the rendering strategy can automatically merge batches and reduce the refresh rate, prioritizing continuous data acquisition while maintaining readable visual feedback as much as possible.

[0024] Threading and Synchronization Strategies: The system employs a data acquisition-first scheduling algorithm and CPU priority mapping: the acquisition thread is configured with high priority to ensure the continuity of DMA and data transfer; the front-end rendering thread is configured with normal or slightly higher priority to ensure smooth visualization without affecting the main acquisition process; the monitoring and logging threads are configured with lower priority, and CPU and I / O usage is reduced through frequency limiting and batch writing strategies. Cross-thread communication uniformly adopts asynchronous signal and message distribution to avoid introducing blocking waits and global lock holding on the acquisition path; shared data is transmitted using read-only snapshots or minimal-granularity locks to ensure that the critical sections for drawing and logging remain short. Under multi-GPU concurrency conditions, thread creation and destruction follow pooling or delayed reuse principles to reduce scheduling jitter caused by frequent connection establishment.

[0025] Performance and Scalability Design: The main process maintains parallel data and state paths based on card indexes to reduce shared lock contention and improve throughput under multi-card concurrency. Regarding communication channels, the number of PCIe and RFM2G paths and bandwidth allocation can be expanded according to device capabilities; simultaneously, lightweight metric reporting and sampling points are deployed on critical paths to form an observable closed loop, thereby supporting subsequent performance tuning and capacity planning.

[0026] Security and fault tolerance mechanisms: The system provides a fast reset path for device and communication anomalies and suppresses log storms by merging similar events in a short period. During periods of continuous anomalies or excessive load, rate limiting and circuit breaking strategies are introduced to prevent problems from being amplified, while retaining the minimum necessary available functionality. Restrictions are gradually lifted as the load decreases or the link recovers.

[0027] Operation Flow and State Transitions (Timing Description): After power-on, the system enters the initial state, completes device enumeration and thread registration, and the monitoring cycle begins. During normal operation, data collection remains continuous, the interface refreshes at a set frame rate, and the monitoring thread samples periodically and generates corresponding prompts. When the fill rate enters a high-occupancy range, the system enters a warning state, the front end issues a general prompt and provides suggested actions; if overflow occurs or a higher threshold is exceeded, the state escalates to an alarm state, and important prompts and event logging are performed. As the indicators decline, the system automatically de-prompts and returns to a stable display, with relevant records retained for subsequent review and analysis.

[0028] Industrial Applicability and Deployment: The system is suitable for multi-card PCIe / RFM2G hardware environments with DMA capabilities. The software utilizes a C++ backend and a Qt frontend, combining thread pools and asynchronous event mechanisms to leverage the advantages of multi-core parallelism. During deployment, it is recommended to allocate CPU and memory resources reasonably based on the number of cards and target throughput, and to direct log output to a separate disk partition to improve stability and fault traceability. Furthermore, this method requires no hardware or driver modifications, has low deployment and migration costs, and possesses good scalability, allowing for the introduction of more prompt categories, log tags, and frontend styles as needed without disrupting the core workflow.

[0029] Under conditions of single or few cards, moderate sampling rate, and low drawing and monitoring load, the system can run continuously, and the fill rate recorded by the monitoring thread remains within the normal range for a long period. In this scenario, the front end usually does not display any prompts, or only displays occasional general prompts that can be quickly recovered. Overall, it exhibits stable operation over a long period, and the method has minimal impact on the continuity of data acquisition and the smoothness of visualization.

[0030] When multiple GPUs run concurrently and the sampling rate increases, or when external services cause a sudden surge in rendering and monitoring overhead, the system experiences a short period of high occupancy. The monitoring thread first captures the rapid increase in fill rate and enters the warning or alarm range. The front end then displays tiered prompts and logs them. Guided by these prompts, the scheduler smooths out peaks and troughs by downsampling, reducing the refresh rate, or pausing non-critical channels, allowing backpressure indicators to gradually decrease and stabilize. Compared to methods without monitoring and prompts, this approach can detect risks earlier and intervene in a timely manner, significantly reducing the probability of data loss.

[0031] Parameter and Configuration Management: The parameter system covers key items such as monitoring cycles, alert thresholds (normal / high usage / critical), and drawing merging strategies. Configuration is primarily file-based, allowing limited dynamic adjustments within safety boundaries during runtime, and recording changes for auditing and rapid rollback. This enables low-risk parameter tuning to achieve optimal performance under different load scenarios.

[0032] Parameter and Timing Recommendations: The recommended sampling period for the monitoring timer is 50–200 ms, which can be increased to 200–500 ms under sudden loads to reduce monitoring overhead; threshold stratification should be: normal <70%, warning 70%–90%, and overflow event triggering important notifications; timer jitter tolerance is ±10%, and a "period deviation" event should be recorded when the tolerance is exceeded; thread priority mapping is recommended as: acquisition thread > front-end refresh thread > monitoring / logging thread; log write frequency limiting recommendations: information ≤ 5 entries / second, warning ≤ 2 entries / second, important events should be written immediately; drawing rate limiting recommendations: spectrum / time domain window refresh rate 10–30 FPS, dropping to 5–15 FPS under high load to maintain interactivity; buffer level is recommended to set a two-level threshold, for example, 80% and 90% corresponding to general and important notifications respectively.

[0033] Parameter calibration and optimization: Initial calibration sets sampling period and threshold stratification based on device capabilities and target scenarios; online optimization focuses on KPIs such as loss rate, refresh latency, and prompt response time, increasing the sampling period or decreasing the window refresh rate under high load; post-mortem optimization adjusts threshold and prompt level mapping based on event statistics such as "period deviation" and "high occupancy duration" in the logs; and parameter configurations are versioned for easy backtracking and batch deployment.

[0034] Measurement and Monitoring Metrics: Key metrics collected by the system include FIFO fill rate, overflow count, sampling and monitoring cycle, and front-end refresh frame rate; auxiliary metrics such as rendering time, number of drawing batches, and event write rate are also recorded. These metrics are exposed in a lightweight manner to the debug window or asynchronously collected to the logs, and aggregation and filtering by card index are supported to locate performance bottlenecks and abnormal hotspots under multi-card concurrency conditions.

[0035] Interoperability and Resource Constraints: The system can collaborate with existing data acquisition, analysis, and alarm systems through log and messaging mechanisms. In resource-constrained environments, the operational strategy prioritizes ensuring basic data acquisition and monitoring functions, and then gradually restores high refresh rates and advanced visualization capabilities. To address differences between devices from different manufacturers and models, an adaptation layer is used to shield underlying differences, ensuring the consistency and stability of core functions.

[0036] Compatibility and Expansion Suggestions: The system has been validated on different versions of Qt and operating systems, maintaining consistency in core functionality. At the expansion level, additional prompt levels and display styles can be added to further refine strategies and interactions. Gradually acquiring more granular state and event metrics by leveraging hardware capabilities will help trigger prompts more accurately and intervene proactively under edge conditions.

[0037] This invention addresses backpressure risks in terahertz signal acquisition systems by providing a lightweight, observable, and intervention-enabled alerting method and device. The solution maintains the existing dual-pipeline and non-blocking principles, prioritizing the main acquisition path and continuous visualization. Without requiring hardware modifications, it significantly improves system stability and maintainability through monitoring, threshold stratification, alerting, and front-end linkage strategies. The overall effect is a significant reduction in data loss rate and interface refresh latency, improved alert response time, and increased operator efficiency. A unified time base and threshold stratification enable tiered alerting and retrospective analysis, while maintaining low deployment costs and good scalability.

[0038] The different module calls and implementations are as follows:

[0039] Module 1: Devices and Protocol Layers (corresponding to...) Figure 1 )

[0040] Function: To complete XDMA channel read / write, register configuration and trigger mode switching, and provide a unified status and data interface for acquisition and monitoring.

[0041] Connection relationships: Provide data (DMA / buffer) to the acquisition pipeline, and provide FIFO water level and overflow events to the monitoring pipeline; multi-card management establishes objects and thread priorities by card index (see...). Figure 3 The device layer exposes only necessary lightweight interfaces and uses an asynchronous / message mechanism to access the upper layer, avoiding cross-thread lock sharing and blocking.

[0042] Module 2: Linkage between data acquisition pipeline and front end (corresponding to...) Figure 1 , Figure 3 )

[0043] Function: Sampling → Buffering → Copying → Updating signal, driving front-end frequency domain / time domain refresh.

[0044] Call path: Acquisition thread issues "Data ready" → Front-end control object forwards → Signal window is drawn; drawing uses on-demand refresh and batch merging to maintain non-blocking. Acquisition thread is set to high priority, and front-end refresh is set to medium priority; frame drops and region updates during high load ensure that acquisition continuity is not affected.

[0045] Module 3: Monitoring and Early Warning Handling (corresponding to) Figure 2 )

[0046] Function: Periodically sample FIFO fill rate and overflow events, perform threshold stratification, and generate prompts / logs.

[0047] Call path: Monitoring thread sampling → Asynchronous queue → Early warning processing → Alert display and log writing; decoupled from the acquisition path, does not block DMA and drawing.

[0048] Tiered strategy: No prompts are given if the percentage is below 70%; general prompts are given if the percentage is between 70% and 90%; important prompts are triggered and recorded immediately if the percentage overflows or exceeds the threshold.

[0049] Module 4: Timing and State Transitions (corresponding to) Figure 3 )

[0050] Function: Describes the transitions from normal state to prompt state to recovery state and the corresponding actions.

[0051] Call path: High usage or overflow triggers entry into the alert state; the indicator falls back and automatically recovers and records the closed-loop event; the front-end prompts and logs use frequency limiting to avoid back pressure.

[0052] Module 5: Data Loading and Patterns (corresponding to...) Figure 3 )

[0053] Functions: Connecting file-based data with real-time streaming data; rendering and rate limiting in single-frequency / triple-frequency modes.

[0054] Call path: The loader standardizes the data and delivers it to the front-end window, which refreshes according to the pattern and coordinates with the collected update signals.

[0055] Module Six: Reflection Memory Communication (corresponding) Figure 1 , Figure 2 )

[0056] Function: Without changing the dual-pipeline and non-blocking principles, it distributes critical status or trigger signals to external devices, supporting linkage on a larger system scale.

[0057] Call path: Low-latency sharing and control signal transmission are achieved through reflection of the memory card.

[0058] Module 7: Parameters and Configuration

[0059] Scope: Key items such as parameter source selection, prompt threshold, sampling period, mode selection, and main trigger card.

[0060] Note: Parameters can be adjusted and persisted online; the prompts and log frequency limiting strategies are consistent with the threshold tiering to ensure stability under multi-load scenarios.

[0061] Module 8: Front-end Presentation Unit

[0062] Function: To refresh the spectrum / time domain graph and display related prompts.

[0063] Call path: Receive data update signals from the acquisition pipeline and prompt events from the monitoring pipeline, and perform synchronous visualization in the user interface.

[0064] Module Nine: Scheduling Unit

[0065] Function: To perform thread priority allocation and non-blocking event dispatch.

[0066] Call path: Configure the priority of each thread during the system initialization phase, and manage the routing and dispatch of asynchronous messages during runtime.

[0067] Module 10: Data Acquisition Unit

[0068] Function: To complete sampling and DMA transfer.

[0069] Call path: Initiate DMA transfer through the device protocol layer, write data to the buffer, and notify the acquisition pipeline for subsequent processing.

Claims

1. A dual-pipeline coordination and backpressure control method for multi-card PCIe acquisition system, characterized in that: Separate data acquisition pipeline and control / monitoring pipeline in the same master, the data acquisition pipeline performs sampling, DMA transfer and spectrum / time domain update, the control / monitoring pipeline performs state sampling and prompt event generation based on back pressure indicators provided by the device side (including FIFO fill rate and overflow event), and drives the front-end interface linkage display through an asynchronous signal and event mechanism.

2. The method of claim 1, wherein, Use scheduling algorithm and CPU priority mapping to ensure acquisition continuity and front-end smoothness: acquisition threads are configured as high priority, front-end rendering threads are normal or slightly higher priority, and monitoring and logging threads are lower priority; event distribution and interface update are performed through non-blocking signals / slots to avoid long cross-thread waiting.

3. The method according to claim 1 or 2, characterized in that, The control / monitoring pipeline samples back pressure indicators in a timer-driven or event-driven manner, with a sampling period configurable to 50-200 ms, and adaptively increases to 200-500 ms to reduce overhead while keeping the acquisition path unblocked during sudden high load.

4. The method of claim 1, wherein, Threshold-based load reduction and overflow prevention strategy: issue a general prompt when the FIFO fill rate exceeds the first threshold T1; Issue an important prompt when the second threshold T2 is exceeded or an overflow event is detected, and perform one or more measures according to the strategy, including reducing the sampling rate, suspending non-critical channels, decimating or windowing data before FFT, and issuing asynchronous instructions to avoid blocking the acquisition thread.

5. The method of claim 1, wherein, Front-end refresh uses a speed limit and degradation rendering algorithm: maintain the target refresh rate under normal conditions, automatically reduce the refresh frequency and rendering resolution or area update range under high load, thereby reducing rendering overhead without changing the data acquisition link.

6. The method of claim 1, wherein, Log recording uses a hierarchical frequency limiting strategy to set different maximum output frequencies for information, warning and important classes, and merges and abstracts when the threshold is exceeded to prevent the log itself from causing back pressure on acquisition and rendering.

7. The method of claim 1, wherein, Running parameters are managed by an external configuration file, including parameter source selection, extreme value index, mode selection, trigger card index, threshold and sampling period, and support online adjustment and persistent saving during operation.

8. The method of claim 1, wherein, When the FIFO is highly occupied or overflowed, the control / monitoring pipeline reports the card index and fill rate through the 'fifoOverflowWarning(cardIndex, fillRatio)' type event to the master, which generates user prompts and writes logs at the warning processing entry; when the fill rate falls below the threshold, the prompt is automatically removed and the recovery event is recorded.

9. An apparatus for implementing the method of any of claims 1-8, comprising: Acquisition unit, monitoring unit, scheduling unit and front-end display unit, the acquisition unit is used for completing sampling and DMA transfer; The monitoring unit is used for performing back pressure indicator sampling and event generation; the scheduling unit is used for thread priority allocation and non-blocking event distribution; the front-end display unit is used for completing spectrum / time domain graph refresh and prompt linkage display.

Images