Method, device and computer equipment for storing pulse data

Abstract

This application relates to a method, apparatus, computer device, computer-readable storage medium, and computer program product for storing pulse data. The method includes: determining pulse data blocks based on single-frame pulse data from a data acquisition device in a direct memory access buffer; determining at least one target solid-state drive (SSD) from a plurality of SSDs based on the current real-time status information of each SSD; determining a descriptor corresponding to the pulse data block based on the pulse data block and the target SSD; and writing the pulse data block to the target SSD based on the descriptor of the pulse data block. Therefore, pulse data blocks can be determined based on single-frame pulse data, and by combining this with the real-time status information of each SSD, a target SSD with better performance can be dynamically selected. Then, based on the descriptor corresponding to each pulse data block, the pulse data block can be written to the target SSD, minimizing the generation of redundant data during data transmission and improving data storage efficiency.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method, apparatus, computer device, computer-readable storage medium, and computer program product for storing pulse data. Background Technology

[0002] During the storage of high-speed pulse data acquired by the data acquisition device, the high-speed pulse signal output by the data acquisition device is transmitted to the acquisition card via optical fiber. The acquisition card then sends the data into the computer memory via a high-speed serial bus interface (Peripheral Component Interconnect Express interface, PCIe). Since acquisition cards mostly use Direct Memory Access (DMA) for transmission, this memory area is also called the DMA buffer. Subsequently, the software program on the computer reads the data from the DMA buffer and writes it to the solid state drive (SSD).

[0003] In related technologies, when computer software programs read pulse data from a data acquisition device from a DMA buffer and store it into an SSD, the pulse data needs to be written to a file buffer first, and then written to the SSD from the file buffer. This tedious process of repeatedly reading and writing data generates redundant data transmission, resulting in low data storage efficiency. Summary of the Invention

[0004] Therefore, it is necessary to provide a pulse data storage method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can improve the efficiency of pulse data storage, in order to address the above-mentioned technical problems.

[0005] In a first aspect, this application provides a method for storing pulse data, including:

[0006] The pulse data block is determined based on the single-frame pulse data from the data acquisition device in the direct memory access buffer;

[0007] Based on the current real-time status information of each solid-state drive (SSD), at least one target SSD is determined from a plurality of SSDs;

[0008] Based on the pulse data block and the target solid-state drive, determine the descriptor corresponding to the pulse data block;

[0009] The pulse data block is written to the target solid-state drive according to the descriptor of the pulse data block.

[0010] In one embodiment, determining the pulse data block based on single-frame pulse data from the data acquisition device in the direct memory access buffer includes:

[0011] If the total data length of a single frame of pulse data exceeds a preset threshold, the single frame of pulse data will be split into multiple pulse sub-data.

[0012] Determine the packet number and sub-data length of each pulse sub-data;

[0013] The timestamp of the single-frame pulse data, the packet number of each pulse sub-data, and the sub-data length are determined as the metadata of each pulse sub-data.

[0014] Each pulse sub-data and its corresponding metadata are identified as a corresponding pulse data block.

[0015] In one embodiment, determining at least one target solid-state drive from a plurality of solid-state drives based on the current real-time status information of each solid-state drive includes:

[0016] The performance parameters of each solid-state drive are determined based on the current real-time status information of each solid-state drive.

[0017] Based on the performance parameters of each of the solid-state drives (SSDs), at least one target SSD that meets the preset performance conditions is determined from the plurality of SSDs.

[0018] In one embodiment, the real-time status information includes at least one of the following: the remaining capacity of the solid-state drive, write speed, operating temperature, total data write volume, and the status of the write task corresponding to the solid-state drive.

[0019] In one embodiment, determining the descriptor corresponding to the pulse data block based on the pulse data block and the target solid-state drive includes:

[0020] The source address of the pulse data block in the direct memory access buffer, the destination address of the target solid-state drive, the data length of the pulse data block, and the pre-allocated next descriptor link address are determined as the descriptor corresponding to the pulse data block.

[0021] In one embodiment, after determining the descriptor corresponding to the pulse data block, the method further includes:

[0022] Add the descriptor corresponding to each pulse data block to the submission queue.

[0023] In one embodiment, writing the pulse data block to the target solid-state drive according to the descriptor of the pulse data block includes:

[0024] The descriptors are retrieved sequentially from the submission queue, and the pulse data block corresponding to the source address is written to the destination address according to the descriptor.

[0025] In response to a write completion operation, a completion flag corresponding to the descriptor is added to the completion queue, and the corresponding descriptor is released from the commit queue.

[0026] In one embodiment, the method further includes:

[0027] Read pulse data blocks from multiple target solid-state drives;

[0028] Filter multiple target pulse data blocks belonging to the same single frame pulse data based on timestamps;

[0029] The multiple target pulse data blocks are spliced ​​together according to the order of the packet sequence number to obtain a single frame of pulse data.

[0030] Secondly, this application also provides a pulse data storage device, comprising:

[0031] The first determining module is used to determine the pulse data block based on the single-frame pulse data from the data acquisition device in the direct memory access buffer;

[0032] The second determining module is used to determine at least one target solid-state drive from multiple solid-state drives based on the current real-time status information of each solid-state drive.

[0033] The third determining module is used to determine the descriptor corresponding to the pulse data block based on the pulse data block and the target solid-state drive;

[0034] The write module is used to write the pulse data block to the target solid-state drive according to the descriptor of the pulse data block.

[0035] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0036] The pulse data block is determined based on the single-frame pulse data from the data acquisition device in the direct memory access buffer;

[0037] Based on the current real-time status information of each solid-state drive (SSD), at least one target SSD is determined from a plurality of SSDs;

[0038] Based on the pulse data block and the target solid-state drive, determine the descriptor corresponding to the pulse data block;

[0039] The pulse data block is written to the target solid-state drive according to the descriptor of the pulse data block.

[0040] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0041] The pulse data block is determined based on the single-frame pulse data from the data acquisition device in the direct memory access buffer;

[0042] Based on the current real-time status information of each solid-state drive (SSD), at least one target SSD is determined from a plurality of SSDs;

[0043] Based on the pulse data block and the target solid-state drive, determine the descriptor corresponding to the pulse data block;

[0044] The pulse data block is written to the target solid-state drive according to the descriptor of the pulse data block.

[0045] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0046] The pulse data block is determined based on the single-frame pulse data from the data acquisition device in the direct memory access buffer;

[0047] Based on the current real-time status information of each solid-state drive (SSD), at least one target SSD is determined from a plurality of SSDs;

[0048] Based on the pulse data block and the target solid-state drive, determine the descriptor corresponding to the pulse data block;

[0049] The pulse data block is written to the target solid-state drive according to the descriptor of the pulse data block.

[0050] The aforementioned method, apparatus, computer equipment, computer-readable storage medium, and computer program product for storing pulse data can first determine pulse data blocks based on single-frame pulse data from the data acquisition device in the direct memory access buffer. Then, based on the current real-time status information of each solid-state drive (SSD), at least one target SSD is selected from multiple SSDs. Next, based on the pulse data blocks and the target SSD, the descriptor corresponding to the pulse data blocks is determined. Finally, the pulse data blocks are written to the target SSDs based on their descriptors. Thus, pulse data blocks can be determined based on single-frame pulse data, and by combining this with the real-time status information of each SSD, a target SSD with better performance can be dynamically selected. Finally, based on the descriptors corresponding to each pulse data block, the pulse data blocks are written to the target SSDs, minimizing the generation of redundant data during data transmission, improving data storage efficiency, and achieving reliable storage of high-speed pulse data. Attached Figure Description

[0051] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0052] Figure 1 This is a flowchart illustrating a method for storing pulse data in one embodiment;

[0053] Figure 2 This is a flowchart illustrating the process of determining a single frame of pulse data based on a pulse data block in one embodiment.

[0054] Figure 3 This is a schematic diagram of the pulse data storage process in one embodiment;

[0055] Figure 4 This is a schematic diagram of the dynamic management process of descriptors in one embodiment;

[0056] Figure 5 This is a schematic diagram of the descriptor structure block diagram in one embodiment;

[0057] Figure 6 This is a structural block diagram of a pulse data storage device in one embodiment;

[0058] Figure 7 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0059] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0060] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0061] In one embodiment, such as Figure 1 As shown, a method for storing pulse data is provided. This embodiment illustrates the application of this method to a terminal. It is understood that this method can also be applied to a server, and further to a system including both a terminal and a server, and implemented through interaction between the terminal and the server. In this embodiment, the method includes the following steps:

[0062] Step 102: Determine the pulse data block based on the single-frame pulse data from the data acquisition device in the direct memory access buffer.

[0063] Typically, during the storage of high-speed pulse data acquired by a data acquisition device, the high-speed pulse signal output by the device is transmitted to the acquisition card via optical fiber. The acquisition card then sends the data into the computer memory via a high-speed serial bus interface (Peripheral Component Interconnect Express interface, PCIe). This memory area can also be called a Direct Memory Access (DMA) buffer. Subsequently, the software program on the computer reads data from the DMA buffer and writes it to a file buffer, and then writes it from the file buffer to a solid state drive (SSD). This tedious process of repeatedly reading and writing data generates redundant data transmission, resulting in low data storage efficiency.

[0064] In this embodiment of the application, in order to improve data storage efficiency and reduce redundant data generated during data transmission, the pulse data block can be determined first based on the single-frame pulse data from the data acquisition device in the DMA buffer.

[0065] The DMA buffer is a target physical memory region in the terminal device, which can be used to temporarily store high-speed pulse data from the data acquisition device. Furthermore, the data acquisition device can be of various types, such as a detector, radar, camera, etc., and this application does not limit its scope.

[0066] In addition, a single-frame pulse data can be the complete pulse data collected by the data acquisition device within one frame time, also known as a pulse data frame. It can be composed of a single-bit 0 / 1 pixel digital array or a multi-bit pixel digital array, etc. This application does not limit it.

[0067] A pulse data block can be understood as a data unit with a unified data structure obtained after processing a single frame of pulse data, which can be used for subsequent storage and writing.

[0068] Optionally, the pulse data block may include metadata describing the pulse data, wherein the metadata may include the pulse data's timestamp, data length, etc., which are not limited in this application.

[0069] Optionally, the process of processing single-frame pulse data may include the terminal setting a preset threshold in advance. If the total data length of the single-frame pulse data does not exceed the preset threshold, the single-frame pulse data and its corresponding metadata can be identified as a pulse data block of the single-frame pulse data. If the total data length of the single-frame pulse data exceeds the preset threshold, the single-frame pulse data is split into multiple pulse sub-data, and then the multiple pulse sub-data are processed to determine their respective corresponding pulse data blocks.

[0070] Optionally, if the total data length of a single frame of pulse data exceeds a preset threshold, the single frame of pulse data can be split into multiple pulse sub-data. Then, the packet number and sub-data length of each pulse sub-data can be determined. The timestamp of the single frame of pulse data, the packet number and sub-data length of each pulse sub-data can be determined as the metadata of each pulse sub-data. Finally, each pulse sub-data and its corresponding metadata can be determined as the corresponding pulse data block.

[0071] The preset threshold can be a pre-defined value, such as 1MB or 2MB, or it can be adjusted according to actual needs. This application does not limit this.

[0072] Understandably, the ratio between the total length of a single frame of pulse data and a preset threshold can be used to determine the number of pulse sub-data. If the ratio is not an integer, it can be rounded up, and the rounded result is the number of pulse sub-data, thereby ensuring data integrity and avoiding data loss.

[0073] In addition, the sub-packet sequence number can be understood as a sequential number, used to identify the arrangement position of the pulse sub-data in its original single-frame pulse data. It can be 8 bits, or it can be other data lengths, etc., which are not limited in this application.

[0074] For example, a single frame of pulse data can be split into three pulse sub-data. Based on the order of these three pulse sub-data in the single frame of pulse data, their packet numbers can be 0, 1, 2; or they can be 1, 2, 3, etc. This application does not limit this.

[0075] It is understood that the timestamp of a single frame pulse data is the timestamp when the pulse data is generated. Correspondingly, multiple pulse sub-data belonging to the same single frame pulse data have the same timestamp. The timestamp can be 32 bits or other data lengths, etc., which is not limited in this application.

[0076] In addition, the sub-data length can be the size of the storage space occupied by each pulse sub-data itself, and the unit can be bytes, bits, etc., such as 24 bits, or other data lengths, etc. This application does not limit this.

[0077] In addition, metadata can be used to describe the relevant attributes of pulse sub-data. The metadata of each pulse data block may include the timestamp of the single frame pulse data to which it belongs, the packet sequence number, the sub-data length, etc. This application does not limit this.

[0078] In addition, the pulse data block can be an independent data unit that is ultimately written into the solid-state drive, and may include pulse sub-data and corresponding metadata, etc. This application does not limit this.

[0079] For example, if the preset threshold is 1MB and the total data length of a single frame pulse data 1 is 3.5MB, it can be split into 4 pulse sub-data. The packet numbers of the 4 pulse sub-data can be 0, 1, 2, and 3 respectively, and the sub-data lengths of the 4 pulse sub-data can be 1MB, 1MB, 1MB, and 0.5MB respectively. If the timestamp of single-frame pulse data 1 is 202X-X-XX, then the timestamp 202X-X-XX, packet sequence number 0, and sub-data length 1MB can be identified as the metadata of pulse sub-data 1. The timestamp 202X-X-XX, packet sequence number 1, and sub-data length 1MB can be identified as the metadata of pulse sub-data 2. The timestamp 202X-X-XX, packet sequence number 2, and sub-data length 1MB can be identified as the metadata of pulse sub-data 3. The timestamp 202X-X-XX, packet sequence number 3, and sub-data length 0.5MB can be identified as the metadata of pulse sub-data 4. Then, the above 4 pulse sub-data and their corresponding metadata can be identified as their respective pulse data blocks.

[0080] It should be noted that the above examples are merely illustrative and should not be taken as limitations on the preset threshold, total data length of a single frame pulse data, packet sequence number, timestamp, sub-data length, metadata, etc. in the embodiments of this application.

[0081] Therefore, in this embodiment, when the total data length of a single frame of pulse data exceeds a preset threshold, it can be split into multiple pulse sub-data. Each sub-data is assigned a packet sequence number, and its length is recorded. The timestamp corresponding to the single frame of pulse data serves as a unified identifier. The timestamp, packet sequence number, and sub-data length constitute the metadata for each pulse sub-data. Finally, each pulse sub-data and its corresponding metadata are combined to form a pulse data block. Thus, by splitting the data, the scale of a single write operation is reduced, ensuring the stability of subsequent solid-state drive writes. The timestamp and packet sequence number enable rapid location, reassembly, and retrieval after multi-disk storage, improving the reliability and parallel processing capability of high-speed pulse data storage.

[0082] Step 104: Based on the current real-time status information of each solid-state drive, determine at least one target solid-state drive from the multiple solid-state drives.

[0083] The terminal device can be configured with multiple solid-state drives (SSDs). When storing pulse data blocks, the target SSD can be determined based on the current real-time status information of each SSD.

[0084] The real-time status information can characterize the actual operating status of the solid-state drive at the current moment, such as the remaining capacity of the solid-state drive, write speed, operating temperature, total data write volume, and the status of the corresponding write task of the solid-state drive.

[0085] For example, real-time status information can be one or a combination of the above information. For instance, real-time status information could be the current remaining capacity of the solid-state drive (SSD), or a combination of the SSD's current operating temperature and write speed, or a combination of the SSD's remaining capacity, write speed, and the status of the corresponding write task, etc. This application does not limit this.

[0086] It should be noted that the above real-time status information is only an example and can be added, deleted or replaced as needed, and this application does not limit it.

[0087] It is understood that the terminal device can filter among multiple solid-state drives (SSDs) in the terminal based on the real-time status information of each SSD. If the real-time status information of an SSD meets a preset status threshold, the SSD can be identified as the target SSD. This application does not limit this.

[0088] The preset state threshold can be a pre-set value, such as the remaining capacity of the solid-state drive being more than 10% of the total capacity, the operating temperature being less than 50℃, etc., or it can be adjusted according to the actual needs of the scenario, etc., and this application does not limit it in this regard.

[0089] Therefore, in this embodiment of the application, the real-time status information of each solid-state drive can be used for filtering to ensure that the identified target solid-state drives all meet the preset status threshold. In this way, during the subsequent pulse data writing and storage process, pulse data is avoided from being written to solid-state drives with poor performance, thus ensuring high storage efficiency and system stability.

[0090] Optionally, in the process of determining the target solid-state drive, the performance parameters of each solid-state drive can be determined first based on the current real-time status information of each solid-state drive, and then at least one target solid-state drive that meets the preset performance conditions can be determined from multiple solid-state drives based on the performance parameters of each solid-state drive.

[0091] Among them, the performance parameters can be indicators that reflect the performance of the solid-state drive, obtained from real-time status information. For example, the corresponding performance parameters can be determined based on the relationship between real-time status information and preset status thresholds. This application does not limit this.

[0092] In addition, the preset performance conditions can be pre-defined filtering rules, such as the highest performance parameter, the performance parameter exceeding a certain threshold, the performance parameter level being excellent, etc. This application does not limit this.

[0093] It is understandable that when there is only one piece of real-time status information, the performance parameter can be determined by that piece of status information. When there are multiple pieces of real-time status information, the performance parameter can be the comprehensive result of the performance corresponding to each real-time status.

[0094] For example, when the real-time status information only shows the remaining capacity, if SSD 1 currently has 90% remaining capacity, SSD 2 has 85% remaining capacity, and SSD 3 has 25% remaining capacity, the performance parameters of each SSD can be recorded as 90%, 85%, and 25% respectively. If the preset performance condition is that the remaining capacity is greater than 30%, then SSD 1 and SSD 2 can be identified as the target SSDs.

[0095] Alternatively, performance grading rules can be pre-defined: Excellent for remaining capacity greater than 60%, Good for 30%-60%, and Poor for less than 30%; Excellent for operating temperature less than 5℃, Good for 5-8℃, and Poor for above 8℃. If SSD 4 has 70% remaining capacity and an operating temperature of 6℃, SSD 5 has 50% remaining capacity and an operating temperature of 3℃, SSD 6 has 20% remaining capacity and an operating temperature of 8.5℃, and SSD 7 has 35% remaining capacity and an operating temperature of 8℃, then the performance grades corresponding to the remaining capacities of SSDs 4-7 are Excellent, Good, Poor, and Good, respectively, and the performance grades corresponding to their respective operating temperatures are Good, Excellent, Poor, and Poor, respectively. If the preset performance condition is that all performance grades are not poor, then the target SSDs can be determined as SSD 4 and SSD 5.

[0096] It should be noted that the above examples are merely illustrative and should not be construed as limiting the real-time status information, performance parameters, preset conditions, etc., in the embodiments of this application.

[0097] Therefore, in this embodiment of the application, the appropriate target solid-state drives can be selected based on the real-time status information of each solid-state drive, so as to achieve reasonable allocation of storage tasks. In this way, load balancing of multiple solid-state drives can avoid overload of a single solid-state drive, ensure the writing efficiency of high-speed pulse data, and enable multiple solid-state drives to work in parallel with high efficiency.

[0098] Step 106: Determine the descriptor corresponding to the pulse data block based on the pulse data block and the target solid-state drive.

[0099] The descriptor can be used to indicate all the information required for pulse data writing from the DMA buffer to the solid-state drive. For example, the descriptor may include the source address of the pulse data block in the DMA buffer, the destination address of the target solid-state drive to be written, the data length of the pulse data block, etc., which are not limited in this application.

[0100] Optionally, the source address of the pulse data block in the direct memory access buffer, the destination address of the target solid-state drive, the data length of the pulse data block, and the pre-allocated next descriptor link address can be determined as the descriptor corresponding to the pulse data block.

[0101] The next descriptor link address can be understood as a memory address recorded in the current descriptor, pointing to the location of the next descriptor to be executed. For example, a memory space can be pre-allocated to store descriptors, with each memory address corresponding to a descriptor, and the descriptors having a pre-defined order. Therefore, in this embodiment, a next descriptor link address can be added to the current descriptor. This address allows multiple independent descriptors to be chained together in execution order, forming a chain structure and providing a foundation for subsequent continuous data transmission.

[0102] In one embodiment, the terminal device can use all the solid-state drives included as the target solid-state drives, and then dynamically adjust the descriptors assigned to them based on the current real-time status information.

[0103] For example, for solid-state drives (SSDs) with higher instantaneous storage speeds, the number of descriptors issued per unit time can be increased accordingly, enabling them to process more pulse data blocks. When the operating temperature of the SSD rises to a preset threshold, the terminal device can gradually reduce the number of descriptors issued to it per unit time until its temperature drops back to a safe range, avoiding overheating and throttling or damage. When the remaining capacity of the SSD is close to the full capacity threshold, the terminal device can reduce the number of descriptors issued to it per unit time, prioritizing the allocation of tasks to SSDs with sufficient remaining capacity. When the write latency of the SSD increases, the terminal device will reduce the number of descriptors issued according to its latency level to avoid high-latency drives slowing down overall write efficiency, etc., but this application does not limit this aspect.

[0104] Therefore, in this embodiment of the application, the terminal device can allocate more descriptors to the target solid-state drive with better performance based on the above-mentioned multi-dimensional status information, so as to achieve load balancing scheduling of high-speed pulse data and ensure overall storage efficiency and stability.

[0105] Optionally, the descriptor corresponding to each pulse data block can be added to the submission queue, enabling the terminal device to uniformly schedule and start batch transmission tasks. After the terminal device obtains the current descriptor from the submission queue and completes the corresponding data transmission, it can automatically find the next descriptor to be executed based on the next descriptor link address recorded in the descriptor, thereby realizing continuous and batch data transmission processing.

[0106] Step 108: Write the pulse data block to the target solid-state drive according to the pulse data block descriptor.

[0107] Understandably, after determining the descriptors of each pulse data block, the source address of the pulse data block in the direct memory access buffer, the destination address of the target SSD to be written, the data length of the pulse data block, and the pre-allocated link address of the next descriptor can be obtained from the descriptors of each pulse data block. Then, the pulse data block of the corresponding data length can be retrieved from the source address and written to the destination address of the target SSD, completing the write operation from pulse data block to target SSD.

[0108] Therefore, in this embodiment of the application, each pulse data block can be written to the target solid-state drive according to the descriptor of each pulse data block, thereby realizing parallel execution of data writing and improving data transmission efficiency.

[0109] Optionally, descriptors can be retrieved sequentially from the submission queue, and the pulse data block corresponding to the source address can be written to the destination address based on the descriptor.

[0110] Specifically, descriptors can be retrieved from the submission queue in a first-in, first-out (FIFO) order. Then, based on the retrieved descriptor, the corresponding data write operation can be executed. If the current descriptor contains a link address for the next descriptor, the write operation for the subsequent descriptor can continue based on that address after the current write operation is completed, thus achieving continuous data transfer.

[0111] Optionally, in response to a write completion operation, a completion flag corresponding to the descriptor is added to the completion queue, and the corresponding descriptor is released from the commit queue.

[0112] The completion queue is used to record the completion status of pulse data writes. Each time a pulse data block is written from the DMA buffer to the target SSD, a corresponding completion flag is added to this queue. Afterwards, the corresponding descriptor in the commit queue can be released, meaning the content recorded on that descriptor is cleared, so that it can be reused to record relevant information for pending pulse data blocks.

[0113] Optionally, in practical applications, the software program can be divided into part A and part B.

[0114] The software program A can be used to read descriptors from the submission queue, and then write the corresponding pulse data block in the DMA buffer to the target solid-state drive based on the descriptor. After the writing is completed, the corresponding completion flag is added to the completion queue.

[0115] Part B of the software program can be used for queue management. If the DMA buffer receives new single-frame pulse data, a corresponding descriptor is added to the submission queue. If a completion flag is detected in the completion queue, the corresponding completed descriptor in the submission queue can be released.

[0116] It should be noted that the division method, functional configuration and number of components of the software program can be adapted to the actual scenario. The above examples are only illustrative and should not be regarded as a limitation on the technical solution of this application.

[0117] Optionally, the process of writing pulse data blocks to the target SSD based on the descriptor can be executed in parallel using multiple threads or processes. This allows for simultaneous copying via multiple processes and threads, fully leveraging the performance advantages of parallel writing across multiple SSDs. Furthermore, the operations of retrieving descriptors from the commit queue and inserting completion markers into the completion queue need to be performed sequentially, while the data copying process can be parallelized.

[0118] In the aforementioned method for storing pulse data, pulse data blocks are first determined based on single-frame pulse data from the data acquisition device in the direct memory access buffer. Then, based on the real-time status information of each solid-state drive (SSD), at least one target SSD is selected from multiple SSDs. Next, based on the pulse data blocks and the target SSD, the descriptor corresponding to the pulse data blocks is determined. Finally, the pulse data blocks are written to the target SSDs based on their descriptors. Thus, pulse data blocks can be determined based on single-frame pulse data, and by combining this with the real-time status information of each SSD, a target SSD with better performance can be dynamically selected. Finally, based on the descriptors corresponding to each pulse data block, the pulse data blocks are written to the target SSDs, minimizing the generation of redundant data during data transmission, improving data storage efficiency, and achieving reliable storage of high-speed pulse data.

[0119] In one exemplary embodiment, such as Figure 2 As shown, a method for storing pulse data is provided, including steps 202 to 206. Wherein:

[0120] Step 202: Read pulse data blocks from multiple target solid-state drives.

[0121] In this process, after writing the pulse data block from the DMA buffer to the target solid-state drive, if it is necessary to read and use the stored pulse data block or perform other processing operations, the stored pulse data block can be read from multiple target solid-state drives to reassemble the pulse data block that was previously split due to the large amount of data, and obtain a complete single frame pulse data.

[0122] Step 204: Filter multiple target pulse data blocks belonging to the same single frame pulse data according to the timestamp.

[0123] Understandably, when splitting a single frame of pulse data during the writing phase, multiple pulse data blocks belonging to the same single frame have the same timestamp. Therefore, during the reading phase, the timestamps can be used to search through each pulse data block to filter out multiple target pulse data blocks belonging to the same single frame, thereby ensuring the integrity of the subsequently reconstructed pulse data as much as possible.

[0124] Step 206: According to the order of the packet sequence number, multiple target pulse data blocks are spliced ​​together to obtain a single frame of pulse data.

[0125] In this process, after filtering out multiple target pulse data blocks belonging to the same single frame pulse data, the multiple target pulse data blocks can be sequentially spliced ​​together according to the packet sequence number recorded in the metadata of each pulse data block, i.e., the order of the packet sequence number, to obtain complete single frame pulse data, thereby minimizing problems such as data disorder, missing or duplicate data.

[0126] Optionally, after determining the pulse data blocks based on the single-frame pulse data, the metadata of multiple target pulse data blocks belonging to the same single-frame pulse data can be used as an index file and written to the target solid-state drive (SSD). This index file can record information such as the timestamp corresponding to the pulse data frame, the total number of packets, and the storage address of each pulse data block on the target SSD. Therefore, when reading pulse data blocks from multiple target SSDs, the index file can be read first, and the corresponding pulse data block can be directly located and read based on the destination address of the target SSD recorded therein, without needing to traverse all SSDs. Simultaneously, the total number of packets in the index file can be used to verify the actual number of pulse data blocks read, confirming whether any data is missing or lost. Thus, data reading based on the index file improves data search and reading efficiency, achieves data integrity verification, and further ensures the accuracy and reliability of the reproduced single-frame pulse data.

[0127] In this embodiment, pulse data blocks can be read from multiple target solid-state drives first. Then, multiple target pulse data blocks belonging to the same single frame pulse data can be filtered according to the timestamp. Then, the multiple target pulse data blocks are spliced ​​together according to the order of the packet sequence number to obtain the single frame pulse data. Thus, pulse data scattered in multiple solid-state drives can be reassembled and read by using the timestamp and packet sequence number, which effectively avoids data disorder, omission or duplication, ensures data integrity and consistency, and improves the accuracy and reliability of high-speed pulse data storage and reuse.

[0128] The pulse data storage method provided in this application can be applied to pulse data storage in any type or scenario. The following section combines... Figure 3The storage process of the pulse data provided in this application is described.

[0129] The process involves determining pulse data blocks based on single-frame pulse data from the data acquisition device in the direct memory access buffer. Then, based on the current real-time status information of each solid-state drive (SSD), at least one target SSD is selected from multiple SSDs. Finally, the descriptor corresponding to the pulse data block is determined based on the pulse data block and the target SSD. This process can be implemented through high-speed real-time data storage access scheduling in the terminal device, which can include descriptor chain scheduling and SSD storage scheduling.

[0130] The descriptor chain scheduling can include descriptor chain state information and descriptor chain queue scheduling. The descriptor chain state information can be used to monitor the number of circular buffer regions, and the descriptor chain queue scheduling can be used to schedule the circular buffers corresponding to the submission queue and completion queue. Solid-state drive (SSD) storage scheduling can execute SSD storage write scheduling based on SSD storage idle information, achieving storage detection and management. Furthermore, by collecting SSD storage status information such as latency statistics, specific SSD storage write scheduling strategies can be determined.

[0131] Subsequently, descriptors can be scheduled through descriptor chain scheduling, and the corresponding pulse data block can be obtained from the source address of the scheduled descriptor in the DMA buffer and written to the destination address of the corresponding target solid-state drive. For example, pulse data block 1 and pulse data block 2 can be written to SSD1 and SSD2 respectively. This application does not limit this.

[0132] Understandably, the descriptor dynamic management process can be as follows: Figure 4 As shown. The terminal device can generate descriptors corresponding to each pulse data block through the pulse data block copying program and add the descriptors to the commit queue. The commit queue can contain multiple descriptors, such as sqe[0], sqe[1]...sqe[n-1]. After completing the writing of a single pulse data block, the terminal device can write the corresponding completion identifier to the completion queue. The completion queue can include multiple completion identifiers, such as cqe[0], cqe[1]...cqe[n-1].

[0133] The pulse data block copying process can trigger kernel processing, such as traversing the descriptors in the commit queue via a commit queue polling thread and updating the write status of the completion queue via an I / O completion polling thread. Kernel processing directly accesses the DMA system buffer through the SSD controller interface, retrieves the pulse data block based on the source address information in the descriptor, and writes the pulse data block to the SSD via the DMA buffer, thus achieving direct memory access from memory to the SSD.

[0134] In addition, the descriptor structure diagram can be as follows: Figure 5 As shown in the diagram. The pulse data block descriptor can include a source address, destination address, data length, and next descriptor link address. The terminal device can chain multiple descriptors together using the next descriptor address, such as descriptor 0 linking to descriptor 1, descriptor 1 linking to descriptor 2, and descriptor 2 linking to the next descriptor link address, forming an ordered transmission sequence. After the terminal device completes the write operation of the pulse data block corresponding to the current descriptor, it can automatically locate and execute the next descriptor without additional scheduling, achieving continuous transmission of batch pulse data. Each descriptor corresponds to a pulse data block in the DMA buffer. The corresponding pulse data block address can be obtained based on the source address in the descriptor, such as buffer0, buffer1, and buffer2, achieving a one-to-one binding between data blocks and descriptors. Each pulse data block can include a 32-bit timestamp, an 8-bit packet sequence number, a 24-bit sub-data length, and pulse sub-data.

[0135] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0136] Based on the same inventive concept, this application also provides a pulse data storage device for implementing the pulse data storage method described above. The solution provided by this device is similar to the implementation described in the above method; therefore, the specific limitations in one or more pulse data storage device embodiments provided below can be found in the limitations of the pulse data storage method described above, and will not be repeated here.

[0137] In one exemplary embodiment, such as Figure 6 As shown, a pulse data storage device 600 is provided, comprising: a first determining module 610, a second determining module 620, a third determining module 630, and a writing module 640, wherein:

[0138] The first determining module 610 is used to determine a pulse data block based on single-frame pulse data from the data acquisition device in the direct memory access buffer.

[0139] The second determining module 620 is used to determine at least one target solid-state drive from multiple solid-state drives based on the current real-time status information of each solid-state drive.

[0140] The third determining module 630 is used to determine the descriptor corresponding to the pulse data block based on the pulse data block and the target solid-state drive.

[0141] The write module 640 is used to write the pulse data block to the target solid-state drive according to the descriptor of the pulse data block.

[0142] In one embodiment, the first determining module 610 is specifically used for:

[0143] If the total data length of a single frame of pulse data exceeds a preset threshold, the single frame of pulse data will be split into multiple pulse sub-data.

[0144] Determine the packet number and sub-data length of each pulse sub-data;

[0145] The timestamp of the single-frame pulse data, the packet number of each pulse sub-data, and the sub-data length are determined as the metadata of each pulse sub-data.

[0146] Each pulse sub-data and its corresponding metadata are identified as a corresponding pulse data block.

[0147] In one embodiment, the second determining module 620 is specifically used for:

[0148] The performance parameters of each solid-state drive are determined based on the current real-time status information of each solid-state drive.

[0149] Based on the performance parameters of each of the solid-state drives (SSDs), at least one target SSD that meets the preset performance conditions is determined from the plurality of SSDs.

[0150] In one embodiment, the real-time status information includes at least one of the following: the remaining capacity of the solid-state drive, write speed, operating temperature, total data write volume, and the status of the write task corresponding to the solid-state drive.

[0151] In one embodiment, the third determining module 630 is specifically used for:

[0152] The source address of the pulse data block in the direct memory access buffer, the destination address of the target solid-state drive, the data length of the pulse data block, and the pre-allocated next descriptor link address are determined as the descriptor corresponding to the pulse data block.

[0153] In one embodiment, the device further includes an adding module for:

[0154] Add the descriptor corresponding to each pulse data block to the submission queue.

[0155] In one embodiment, the writing module 640 is specifically used for:

[0156] The descriptors are retrieved sequentially from the submission queue, and the pulse data block corresponding to the source address is written to the destination address according to the descriptor.

[0157] In response to a write completion operation, a completion flag corresponding to the descriptor is added to the completion queue, and the corresponding descriptor is released from the commit queue.

[0158] In one embodiment, the method further includes:

[0159] Read pulse data blocks from multiple target solid-state drives;

[0160] Filter multiple target pulse data blocks belonging to the same single frame pulse data based on timestamps;

[0161] The multiple target pulse data blocks are spliced ​​together according to the order of the packet sequence number to obtain a single frame of pulse data.

[0162] Each module in the aforementioned pulse data storage device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0163] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 7As shown, the computer device includes a processor, memory, input / output interface, communication interface, display unit, and input device. The processor, memory, and input / output interface are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interface. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The input / output interface is used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When executed by the processor, the computer program implements a method for storing pulse data. The display unit is used to form a visually visible image and can be a display screen, projection device, or virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0164] Those skilled in the art will understand that Figure 7 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0165] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0166] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0167] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0168] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0169] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0170] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0171] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for storing pulse data, characterized in that, The method includes: The pulse data block is determined based on the single-frame pulse data from the data acquisition device in the direct memory access buffer; Based on the current real-time status information of each solid-state drive (SSD), at least one target SSD is determined from a plurality of SSDs; Based on the pulse data block and the target solid-state drive, determine the descriptor corresponding to the pulse data block; The pulse data block is written to the target solid-state drive according to the descriptor of the pulse data block.

2. The method according to claim 1, characterized in that, The step of determining the pulse data block based on the single-frame pulse data from the data acquisition device in the direct memory access buffer includes: If the total data length of a single frame of pulse data exceeds a preset threshold, the single frame of pulse data will be split into multiple pulse sub-data. Determine the packet number and sub-data length of each pulse sub-data; The timestamp of the single-frame pulse data, the packet number of each pulse sub-data, and the sub-data length are determined as the metadata of each pulse sub-data. Each pulse sub-data and its corresponding metadata are identified as a corresponding pulse data block.

3. The method according to claim 1, characterized in that, The step of determining at least one target solid-state drive from multiple solid-state drives based on the current real-time status information of each solid-state drive includes: The performance parameters of each solid-state drive are determined based on the current real-time status information of each solid-state drive. Based on the performance parameters of each of the solid-state drives (SSDs), at least one target SSD that meets the preset performance conditions is determined from the plurality of SSDs.

4. The method according to claim 3, characterized in that, The real-time status information includes at least one of the following: the remaining capacity of the solid-state drive, write speed, operating temperature, total data write volume, and the status of the write task corresponding to the solid-state drive.

5. The method according to claim 1, characterized in that, The step of determining the descriptor corresponding to the pulse data block based on the pulse data block and the target solid-state drive includes: The source address of the pulse data block in the direct memory access buffer, the destination address of the target solid-state drive, the data length of the pulse data block, and the pre-allocated next descriptor link address are determined as the descriptor corresponding to the pulse data block.

6. The method according to claim 5, characterized in that, After determining the descriptor corresponding to the pulse data block, the method further includes: Add the descriptor corresponding to each pulse data block to the submission queue.

7. The method according to claim 6, characterized in that, The step of writing the pulse data block to the target solid-state drive according to the descriptor of the pulse data block includes: The descriptors are retrieved sequentially from the submission queue, and the pulse data block corresponding to the source address is written to the destination address according to the descriptor. In response to a write completion operation, a completion flag corresponding to the descriptor is added to the completion queue, and the corresponding descriptor is released from the commit queue.

8. The method according to claim 1, characterized in that, The method further includes: Read pulse data blocks from multiple target solid-state drives; Filter multiple target pulse data blocks belonging to the same single frame pulse data based on timestamps; The multiple target pulse data blocks are spliced ​​together according to the order of the packet sequence number to obtain a single frame of pulse data.

9. A pulse data storage device, characterized in that, The device includes: The first determining module is used to determine the pulse data block based on the single-frame pulse data from the data acquisition device in the direct memory access buffer; The second determining module is used to determine at least one target solid-state drive from multiple solid-state drives based on the current real-time status information of each solid-state drive. The third determining module is used to determine the descriptor corresponding to the pulse data block based on the pulse data block and the target solid-state drive; The write module is used to write the pulse data block to the target solid-state drive according to the descriptor of the pulse data block.

10. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 8.

Images