A method for testing consistency of dirty disc performance of a solid state disc on multiple platforms

Abstract

This invention relates to the field of data storage technology and discloses a method for testing the consistency of dirty disk performance of solid-state drives (SSDs) across multiple platforms. The method includes: acquiring the configuration information of the SSD under test and recording the SMART data baseline; initializing the SSD and performing steady-state preprocessing in its empty state after initialization, recording the performance data at this time as an empty disk benchmark; filling the dirty disk ratio of the SSD to a target value through sequential or random write operations; applying a corresponding dynamic load model under the dirty disk ratio, continuously sampling performance, recording performance data, and generating a performance degradation curve; and simultaneously running the SSD performance benchmark test, initiating CPU stress testing, memory bandwidth testing, and GPU load testing in the background. This invention enables cross-testing on both AMD and Intel platforms, systematically evaluating the performance compatibility of SSDs under different system environments.

Description

Technical Field

[0001] This invention relates to the field of data storage technology, and in particular to a method for testing the consistency of dirty disk performance of solid-state drives across multiple platforms. Background Technology

[0002] Solid-state drives (SSDs) performance, especially write speeds, is not static. Their performance is highly dependent on the remaining available disk space (OP space) and the state of the garbage collection (GC) mechanism. Newly manufactured SSDs are in an "empty" state, exhibiting optimal performance. As user data is continuously written, the SSD's NAND flash blocks gradually fill up, entering a "dirty" state. At this point, the available OP space decreases, and the controller needs to perform a time-consuming erase operation before writing new data, resulting in a significant drop in write performance. Therefore, comprehensively evaluating the performance of an SSD from an empty to a full disk under different "dirty" states is crucial for accurately reflecting the user experience.

[0003] Existing technologies: "Ideal State" Benchmarking: This is the most common performance evaluation method. Testing is conducted only when the SSD is empty or in a clean state after a secure erase. Standard software such as CrystalDiskMark (CDM) and AS SSDBenchmark are used to perform one or a few peak performance benchmarks, which are then published as the SSD's performance metric. "Single Dirty Disk State" Testing: Some more advanced tests perform performance testing after a certain amount of data (e.g., 50%) has been written to the SSD. However, this type of test often only selects an isolated percentage point of dirtiness, failing to depict a complete performance curve as the degree of dirtiness changes. Summary of the Invention

[0004] This invention provides a method for testing the consistency of dirty disk performance of solid-state drives across multiple platforms, which can solve the technical problem that insufficient test coverage may lead to the omission of critical point defects due to single dirty disk point testing.

[0005] To solve the above-mentioned technical problems, one technical solution adopted by the present invention is: to provide a method for testing the performance consistency of dirty disks on multiple platforms of solid-state drives, the method comprising:

[0006] Obtain the configuration information of the solid-state drive under test and record the SMART data baseline;

[0007] Initialize the solid-state drive (SSD), and in the empty disk state after initialization, perform steady-state preprocessing and record the performance data at this time as the empty disk baseline.

[0008] By sequential or random writing, the dirty disk ratio of the solid-state drive is filled to the target value. Under the dirty disk ratio, a corresponding dynamic load model is applied, and performance sampling and recording are continuously performed to generate a performance degradation curve.

[0009] While running solid-state drive (SSD) performance benchmark tests, CPU stress tests, memory bandwidth tests, and GPU load tests are launched in the background to assess the SSD's tolerance to system resource contention and to determine the consistency of the SSD's performance data.

[0010] Using machine learning algorithms, a model is built based on the performance degradation curve and changes in SMART data, and the performance of solid-state drives is predicted based on the model after long-term use.

[0011] After the test is completed, the solid-state drive will automatically generate a detailed PDF report containing all test data, curves, charts, consistency indices, and a visual digital profile.

[0012] The beneficial effects of this invention are as follows: By simulating the entire lifecycle of a user's SSD from initial use to full disk usage, and sampling performance at multiple key dirty disk nodes (empty disk, 30% / 40%, 70%, 100%), the test results are no longer "ideal values" from the laboratory, but rather a "practical guide" that can accurately predict the performance of SSDs in real-world use, providing unprecedentedly reliable basis for consumer procurement and system integrator selection. Furthermore, it plots the performance degradation curve of SSDs as the dirty disk ratio changes. By comparing the curves of different SSDs, the garbage collection efficiency of their controller and firmware, the merits of their SLC caching strategies, and the level of performance consistency can be clearly and quantitatively evaluated. By testing at representative dirty disk ratio points (such as the SLC cache exhaustion point of TLC / QLC), this invention can effectively stimulate and identify defects that are completely hidden under empty disk testing. The requirement for cross-testing on both AMD and Intel platforms enables a systematic evaluation of SSD performance compatibility under different system environments. This helps identify performance issues related to specific platform drivers or configurations, ensuring that SSD products can provide stable and reliable performance across a wider user base, and greatly enhancing the product's market adaptability and competitiveness. Attached Figure Description

[0013] Figure 1 This is a flowchart illustrating the multi-platform dirty disk performance consistency test method for solid-state drives according to the first embodiment of the present invention.

[0014] Figure 2 yes Figure 1 A flowchart illustrating step 1.

[0015] Figure 3 yes Figure 1 A flowchart illustrating step 2.

[0016] Figure 4 yes Figure 1 A flowchart illustrating step 3.

[0017] Figure 5 yes Figure 1 A flowchart illustrating step 4.

[0018] Figure 6 yes Figure 1 A flowchart of step 5 in the middle.

[0019] Figure 7 yes Figure 1 A flowchart illustrating step 6. Detailed Implementation

[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0021] The terms "comprising" and "having," and any variations thereof, used in this invention are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus.

[0022] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0023] Figure 1 This is a flowchart illustrating the multi-platform dirty disk performance consistency testing method for solid-state drives according to the first embodiment of the present invention. Figure 1 As shown, the system includes hardware and software components:

[0024] Step 1: Obtain the configuration information of the solid-state drive to be tested and record the SMART data baseline;

[0025] Step 2: Initialize the solid-state drive (SSD), and in the empty disk state after initialization, perform steady-state preprocessing and record the performance data at this time as the empty disk baseline.

[0026] Step 3: Fill the dirty disk ratio of the solid-state drive to the target value by sequential or random writing. Under the dirty disk ratio, apply the corresponding dynamic load model, continuously sample and record performance data, and generate a performance degradation curve.

[0027] Step 4: While running the SSD performance benchmark test, start the CPU stress test, memory bandwidth test and GPU load test in the background to evaluate the SSD's tolerance to system resource contention and determine the consistency of the SSD's performance data.

[0028] Step 5: Use machine learning algorithms to build a model based on the performance degradation curve and changes in SMART data, and predict the performance of the solid-state drive after long-term use based on the model.

[0029] Step 6: After the test is completed, the solid-state drive will automatically generate a detailed PDF report containing all test data, curves, charts, consistency indices, and a visual digital profile.

[0030] Configuration information collection: First, use the system's built-in Device Manager (Windows) or the lshw command (Linux) to confirm the SSD's model, production batch, nominal capacity, interface type (such as SATA 3.0, NVMe 1.4), flash memory type (TLC / QLC / MLC), and cache capacity; then use the manufacturer's official tools (such as Samsung Magician, Intel SSD Toolbox) to supplement details such as firmware version and supported protocols (such as PCIe 4.0), ensuring that the information covers all dimensions of "hardware specifications - software compatibility".

[0031] SMART data logging: Use CrystalDiskInfo (Windows) or smartmontools (cross-platform) to read SMART data, focusing on recording key parameters—cumulative write volume (TBW), cumulative power-on time, bad block count (parameter 05), erase count, remaining lifetime percentage, and temperature fluctuation range; read data three times consecutively at 5-minute intervals. If the fluctuation of the same parameter is less than 2%, take the average value as the baseline to avoid random errors from a single read; abnormal data (such as a non-zero bad block count) should be marked separately to confirm whether it is the initial factory state.

[0032] Integrate the configuration information with the SMART baseline into an "Initial Information Document", noting the acquisition time and test environment temperature (preferably 20-25℃) to avoid environmental factors interfering with subsequent tests.

[0033] Clear any remaining data from the solid-state drive (SSD) to allow it to enter a stable, empty state and obtain an undisturbed initial performance benchmark.

[0034] Initialization procedure: Use the ecure Erase method for initialization—enter erase mode through the manufacturer's tools or motherboard BIOS to avoid using system format (which may leave residual partition information); before erasing, ensure that the SSD is disconnected from other data connections, and restart the device after erasing is complete. Use disk management tools to confirm that the hard drive shows "unallocated" to ensure that the data is completely erased.

[0035] Steady-state preprocessing: Use sequential read / write tools (such as fio, DiskSpd) to perform cyclic read / write processing on the empty disk, with the read / write block size set to 128MB, covering 1.5 times the total disk capacity, and looping 3-5 times; record the continuous read / write speed after each loop, and determine that the disk has entered a steady state when the speed fluctuation between two adjacent loops is less than 5% (to avoid the performance inflation caused by the initial cache effect of the solid-state drive).

[0036] Empty disk benchmark test: Under steady state, use AS SSD Benchmark or CrystalDiskMark to perform performance tests. The test items include sequential read and write speed (1GB file), 4K random read and write speed (queue depth 1 / 8 / 32), average latency and IOPS; each item is repeated 3 times, and the average value is taken as the empty disk benchmark data. At the same time, the CPU usage during the test (must be less than 10%) is recorded to eliminate system resource interference.

[0037] Simulate disk usage under different usage scenarios, track the performance degradation pattern as the proportion of dirty disks changes, and generate a visual degradation curve.

[0038] Dirty Disk Ratio Filling: Set 4 typical target dirty disk ratios (30%, 50%, 70%, 90%), and calculate the corresponding filling data volume based on the actual capacity of the solid-state drive; there are two filling methods - sequential filling with 1GB large files (simulating video storage scenario) and random filling with 4K small files (simulating system partition scenario). The filling tool is fio. During the filling process, the disk usage rate is monitored in real time, and the process stops after the target ratio is reached.

[0039] Dynamic load application: Match the corresponding load model to different dirty disk ratios—30% / 50% ratio applies "light office load" (read / write ratio 7:3, IOPS 500-1000, block size 4K), 70% / 90% ratio applies "heavy server load" (read / write ratio 3:7, IOPS 5000-10000, block size 128K); the load is continuously applied through the fio script to ensure load stability (fluctuation range less than 8%).

[0040] Performance Sampling and Curve Generation: After the load is applied, performance data (including continuous read / write speed, 4K random read / write latency, and IOPS) is sampled every 5 minutes. Sampling continues for 2 hours under each dirty disk ratio, resulting in a total of 24 sets of data. The performance data under the same dirty disk ratio is sorted by time, and a single index decay curve is generated with "time" as the horizontal axis and "performance index value" as the vertical axis. The corresponding dirty disk ratio and load type are also labeled to intuitively present the performance decline trend.

[0041] Verify the performance stability of the solid-state drive when the system's CPU, memory, and GPU resources are under strain, and determine its anti-interference capability and data consistency.

[0042] Simultaneous multi-load operation: Launch the solid-state drive performance benchmark test (using AS SSD Benchmark, with 4K random read and write tests), and simultaneously launch three types of resource stress tests in the background: CPU stress test using Prime95 (selecting "Blend" mode, using 80% of core resources), memory bandwidth test using MemTest86+ (continuous read and write to memory, using 70% of memory capacity), and GPU load test using 3DMark (running "Time Spy" mode, maintaining GPU utilization above 90%); monitor the utilization of each resource in real time through Task Manager to ensure continuous and stable stress.

[0043] Tolerance assessment: Compare the SSD performance data under "no resource contention" and "resource contention" conditions. If the sequential read / write speed deviation is less than 10%, the 4K random latency fluctuation is less than 15%, and the IOPS difference is less than 8%, the tolerance is considered good. If the deviation of any indicator exceeds 20%, it is necessary to check whether it is due to interference from the test environment (such as abnormal background processes) and retest twice to confirm the results.

[0044] Consistency assessment: In resource contention scenarios, the solid-state drive performance is tested three times consecutively. If the deviation of the three test results for the same indicator is less than 3%, it indicates that the performance data consistency meets the standard. If the deviation exceeds 5%, the resource scheduling conflict between the stress testing tool and the solid-state drive testing tool needs to be checked. The tool startup order should be adjusted and the test should be repeated.

[0045] Based on historical performance degradation data and SMART change trends, a predictive model is established to predict the performance of solid-state drives after long-term use.

[0046] Data preparation: Organize the preceding test data—performance characteristics include the performance degradation rate under each dirty disk ratio (e.g., the percentage decrease in read / write speed per 100 hours) and the average latency increase; SMART characteristics include the cumulative write volume change rate (increase in TB per hour), bad block count increment, and remaining lifetime decrease rate; divide the data into a "7:3" ratio for training set (for model learning) and test set (for model validation), and label the corresponding time nodes of the data.

[0047] Model selection and training: Random forest regression algorithm (suitable for multi-feature nonlinear relationships, with strong anti-overfitting ability) or LSTM neural network (suitable for time series data, good at capturing long-term changing trends) is selected; "performance features + SMART features" are used as input, and "read / write speed and remaining lifespan in the next 1 / 3 years" are used as output. The model is trained using Python (using the scikit-learn library or TensorFlow library) - during training, hyperparameters (such as the number of trees in the random forest and the number of hidden layer nodes in the LSTM) are adjusted, and the model accuracy is optimized through cross-validation.

[0048] Model Validation and Prediction: The model accuracy is validated using test set data. If the mean absolute error (MAE) between the predicted and actual values ​​is less than 5% and the root mean square error (RMSE) is less than 8%, the model is considered effective. Based on the effective model, the current SMART data and recent performance degradation trend are input, and the long-term prediction results are output—such as "when the cumulative write volume reaches 150TB in 3 years, the continuous read and write speed will drop to 78% of the initial value, and the remaining lifetime will be 62%." At the same time, a prediction range (such as ±3% error range) is generated to improve the prediction reliability.

[0049] Integrate all test data and analysis results to generate a structured, visualized PDF report for easy interpretation and archiving. Report structure design: The report is divided into 6 core modules—Test Overview (test hard drive configuration, test environment, test period), Basic Data (SMART baseline, empty disk benchmark data), Performance Degradation Analysis (degradation curves for each dirty disk ratio, key indicator change table), Resource Tolerance Results (data comparison with and without competition scenarios, consistency index), Long-term Prediction (model prediction curve, 3-year performance trend chart), and Conclusions and Recommendations (performance level assessment, recommended use cases). Each module is accompanied by corresponding charts (such as line charts and bar charts) to avoid purely text-based presentation.

[0050] Visual elements are created as follows: the performance degradation curve uses a line chart (with data points and trend lines marked), the resource contention comparison uses a bar chart (divided into "no contention" and "contention"), and the trend prediction uses a shaded line chart (shading indicates the error range); the digital profile section presents the overall performance of the solid-state drive through a radar chart - dimensions include "empty disk performance", "dirty disk stability", "resource tolerance" and "lifespan prediction", each dimension is scored from 1 to 10 points, intuitively showing the advantages and disadvantages.

[0051] Automatic generation and export: Use Python's ReportLab library or JasperReports tool to write a report generation script—set a rule to "automatically trigger the script after the test ends," the script reads data files from each step (such as performance data in CSV format, charts in PNG format), fills in the content according to the preset structure, and automatically generates a PDF file; before exporting, check the clarity of the charts (resolution not less than 300dpi) and the accuracy of the data annotations (no incorrect or missing values) to ensure that the report can be directly used for test conclusion output.

[0052] Figure 2 yes Figure 1 The flowchart for step 1 is as follows: Figure 2 As shown, step 1 includes: step 101, obtaining the configuration information of the solid-state drive to be tested, and recording key hardware information such as firmware version, controller model, NAND flash memory type, presence and size of DRAM cache, and simulated SLC cache strategy; step 102, performing SMART data baseline recording, and recording all readable attribute SMART data completely in the empty disk state.

[0053] Comprehensive acquisition of core hardware parameters of solid-state drives (SSDs) is achieved, establishing a complete SMART health baseline with no residual data on the disk. This provides accurate foundational data for subsequent performance analysis, hardware compatibility assessment, and health tracking. Core hardware configuration information is collected using a three-tiered approach: basic tools, professional tools, and vendor tools, ensuring no critical hardware information is missed. Basic specifications and firmware information are initially collected using system tools—on Windows, open "Device Manager - Disk Drives" to view the hard drive model, nominal capacity, and interface type (e.g., SATA 3.0, NVMe 2.0); on Linux systems, execute `lsblk -f` to view the model and partition status, and then use `nvme list` (NVMe hard drives) or `sata-smart-util` (SATA hard drives) to read the firmware version.

[0054] Core hardware details: Use professional tools to delve into key parameters—SSD-Z (or HardDisk Sentinel) on Windows, and `nvme id-ctrl / dev / nvme0n1` (NVMe hard drive) or `hdparm -I / dev / sda` (SATA hard drive) on Linux. Key points to record: controller model (e.g., Samsung Phoenix, Phison PS5021-E21T); NAND flash memory type (clearly TLC / QLC / MLC; if mixed, specify the proportion, e.g., "TLC primary + 16GB SLC cache"); DRAM cache status (distinguish between present and absent); if cached, record the capacity, e.g., "1GB LPDDR4"; if cached, indicate "no independent DRAM, relies on host memory cache"); simulated SLC caching strategy (confirmed with vendor tools, such as Samsung Magician's "Cache Settings" module, Intel SSD...). Toolbox's "Performance Optimization" page records the policy type, such as "Dynamic Capacity Cache (10GB when the disk is empty, reduced to 2GB when the disk is dirty)" and "Fixed Capacity Cache (always maintain 8GB)". Information Verification: Compare the collected hardware parameters with the manufacturer's official product specifications. If discrepancies are found (e.g., the tool displays "QLC" but the official website labels it "TLC"), confirmation with the manufacturer's technical support is required. Correct the records based on the official website data to avoid tool recognition errors.

[0055] The process of creating an empty disk state and recording complete SMART data involves first completing the SSD empty disk processing, and then performing SMART full attribute recording to ensure that the baseline data is uninterrupted. Empty disk state creation: First, follow the "Secure Erase" procedure—enter erase mode through the motherboard BIOS (confirm that the motherboard supports this function), or use a manufacturer-specific erase tool (such as Kingston SSD Manager's "Secure Erase" function); after the erase is complete, restart the device and enter a disk management tool (Windows) or fdisk -l (Linux) to confirm that the hard drive shows "unallocated" and has no hidden partitions or residual data, thus determining it to be in a "standard empty disk state".

[0056] Complete SMART data acquisition: Use a tool that supports full attribute reading. On Windows, CrystalDiskInfo is preferred (enable the "Show all SMART attributes" option, and check "Show all" in "Features - Advanced Features - SMART Information"). On Linux, use smartctl -a / dev / sda (SATA hard drive) or smartctl -a / dev / nvme0n1 (NVMe hard drive).

[0057] Recording Requirements: Record all "readable attributes" line by line, including attribute ID (e.g., 01, 05, 09), attribute name (e.g., "read error rate", "remapped sector count", "cumulative power-on time"), current value, threshold, original value, and status (normal / warning / fault). Even "unused" or "meaningless" attributes (e.g., some manufacturer-defined attributes) must be marked "attribute exists, no valid data" to avoid omissions. Stability Verification: In an empty disk state, read SMART data twice consecutively at 10-minute intervals and compare the original values ​​of the two data (e.g., cumulative power-on time, bad block count). If they are completely consistent (no fluctuations), take the first data as the baseline. If there are slight fluctuations (e.g., temperature difference ±1℃), take the average value and mark it to ensure that the baseline data reflects the true health status of the empty disk.

[0058] The "Hardware Configuration Information" and "Empty Disk SMART Full Attribute Data" should be integrated into an "Initial State Baseline Document". The document should include: Hardware Information: Logically sorted by "Model-Firmware Version-Controller-Flash Memory-Cache-Cache Strategy", with each item labeled with the acquisition tool and acquisition time; SMART Data: Listing the complete parameters of all readable attributes line by line with "Attribute ID + Name" as the header, with screenshots of the tool (labeled with acquisition time) as evidence; Remarks: Record the empty disk construction method (e.g., "Secure Erase executed via Samsung Magician at 14:00 on 2025-11-12"), test environment temperature (20-25℃) and humidity (40%-60%) to eliminate environmental variable interference for subsequent data comparison.

[0059] Figure 3 yes Figure 1 The flowchart for step 2 is as follows: Figure 3 As shown, step 2 includes: step 201, adding ARM platform and new generation platform on the basis of the original AMD / Intel platform; step 202, performing full disk sequential write and secure erase to ensure that the solid-state drive is in the initialization stage and to ensure that the starting point of each test is absolutely consistent; step 203, in the empty disk state after initialization, performing low queue depth performance test QD1-QD3 for the random read and write performance of the solid-state drive.

[0060] Step 204: In the initial empty disk state, perform steady-state preprocessing and record the performance data at this time as the empty disk benchmark to ensure that the SSD remains stable during the test.

[0061] Covering multiple architecture test platforms, this system comprehensively collects core hardware parameters of solid-state drives (SSDs), providing fundamental data for performance comparisons and hardware compatibility analysis across different platforms. In addition to the existing AMD / Intel x86 platforms, two new test platforms have been added, clearly defining the differences in tool selection and operation for each platform.

[0062] ARM architecture platform: Select a motherboard equipped with ARMv8-A or higher architecture (such as Rockchip RK3588, NVIDIA Jetson AGX Orin), and install an ARM version of Linux system (such as Ubuntu Server 22.04 ARM64); for hardware information collection tools, use lsblk (basic specifications), nvme-cli (ARM version, used for reading NVMe hard drive parameters), and smartmontools-arm64 (SMART data reading); it is necessary to verify the compatibility of vendor tools in advance (for example, Samsung Magician does not currently support ARM, so use general tools instead), and record the platform CPU model, memory capacity (at least 16GB to avoid memory bottlenecks), and interface protocol version (such as PCIe 4.0 ARM compatibility).

[0063] The new generation x86 platform covers Intel's 14th generation Core processors (such as the i7-14700K) and AMD Ryzen 8000 series processors (such as the Ryzen 9 8950X) platforms, paired with motherboards supporting PCIe 5.0 (such as Z790 and X670E). The hardware information collection tool has been supplemented with Intel Processor Identification Utility (to confirm the PCIe lane allocation of the Intel platform) and AMD Ryzen Master (to check the storage controller mode of the AMD platform), focusing on recording the platform's support status for the NVMe 2.0 protocol and PCIe 5.0 x4 bandwidth, to avoid performance not being fully released due to platform hardware limitations.

[0064] Cross-platform consistency control: All platforms use the same auxiliary hardware (such as 16GB×2 DDR5-5600 memory, 750W or higher gold-rated power supply), and all systems have hibernation, automatic updates, and background antivirus software disabled to ensure that the test environment is consistent except for the platform architecture, and to reduce interference from irrelevant variables.

[0065] It retains the three-tiered data collection method of "basic tools + professional tools + vendor tools," and adds multi-platform operation details:

[0066] ARM platform-specific data collection: Execute `nvme id-ctrl / dev / nvme0n1 | grep "mn\|fr\|md"` to read the hard drive model, firmware version, and controller model; after confirming whether it is an SSD by using `cat / sys / block / nvme0n1 / queue / rotational`, use `hdparm -I / dev / nvme0n1` (hdparm needs to be manually installed on some ARM systems) to read the flash memory type and cache information; to simulate the SLC caching strategy, the `fio` tool needs to be used to perform a 10GB file sequential write, recording the speed decay nodes (e.g., if the write speed is 3000MB / s for the first 5GB and then drops to 1500MB / s, it is determined to be a 5GB dynamic SLC cache).

[0067] For next-generation x86 platforms, the following data collection methods are used: Intel SSD Toolbox (updated to a version that supports 14th generation CPUs) is used to read the DRAM cache size on Intel platforms, and Crucial Storage Executive is used to check the cache configuration on AMD platforms. For hard drives that support PCIe 5.0, the link width (whether it is running at ×4) and speed (whether it is 5.0 GT / s) must be confirmed using the PCIe Scanner tool to ensure that the hardware parameter collection covers the characteristics of the next-generation platform.

[0068] Information verification: A new cross-platform parameter comparison step has been added—the same hard drive parameters (such as firmware version and flash memory type) collected from ARM and x86 platforms are verified for consistency. If there are differences (such as the ARM system showing "no DRAM cache" but the x86 showing "1GB cache"), it is necessary to confirm with the manufacturer's official website specifications and correct the records based on the official website data.

[0069] By performing a dual operation of "full disk write + secure erase", the historical data and block state differences of the hard drive are completely cleared, ensuring that the starting point of each test is absolutely consistent and eliminating the impact of initialization deviation on subsequent performance.

[0070] Pre-processing: Sequential full disk write: All test platforms use the same process.

[0071] Tools and parameter settings: Use the fio tool (cross-platform compatible) to write the write script, and set the parameters to "sequential write (write=100%), block size 128MB, IO depth 8, file size equal to the actual hard drive capacity (e.g., 1000GB for a 1TB hard drive), read / write mode is direct IO (to avoid system cache interference)". For ARM platforms, ensure that NVMe / SATA driver support is enabled when compiling fio, and for new generation x86 platforms, disable PCIe power saving mode (through motherboard BIOS settings).

[0072] Execution and Verification: After the script completes the full disk write, read and verify the data using dd if= / dev / zero of= / dev / nvme0n1bs=1G count=10 (selecting the first 10GB) to confirm that there are no residual errors; record the average speed and time taken during the write process as a reference indicator for subsequent initialization consistency (if the difference in time between two tests exceeds 5%, hardware failure needs to be investigated).

[0073] Secure erase operation: Performed on the basis of full disk write, with clear operation details for each platform.

[0074] x86 platform (AMD / Intel / Next Generation): First, enter the "Storage Security" menu through the motherboard BIOS, select the hard drive to be tested, and execute "Secure Erase". If the BIOS does not support it, use the manufacturer's tools (such as Samsung Magician, Kingston SSD Manager). Before erasing, you need to ensure that the hard drive has been password protected (some tools have a default password, which needs to be cleared manually). After erasing, restart and confirm through "Disk Management" that the hard drive shows "Unallocated" and there are no partition remnants.

[0075] ARM platform: Perform a secure erase using `nvme format / dev / nvme0n1 -s 1` (NVMe hard drive) or `hdparm --security-erase-enhanced user / dev / sda` (SATA hard drive, you need to execute `hdparm --security-set-pass user / dev / sda` to set a temporary password first); after erasing, use `lsblk` to confirm that the hard drive capacity is displayed normally and there is no "unrecognized partition" label.

[0076] After each initialization, perform two verifications: SMART data verification: read "cumulative write volume (TBW)" and "remapped sector count" to ensure consistency with the empty disk baseline (Chapter 1 record) and no additional write volume increase; Quick performance verification: perform a 1-minute 4K random read / write test (QD1) and record IOPS and latency. If the test results after two consecutive initializations deviate by more than 3%, a full disk write and secure erase must be re-executed until the deviation meets the requirements.

[0077] Complete performance testing for low queue depth scenarios, and establish a unified empty disk benchmark through standardized steady-state preprocessing, covering two core scenarios: daily use and performance stability. Execute immediately after initialization on an empty disk, focusing on everyday office scenarios with QD1-QD3: Test parameters are uniformly set as follows: Test type: 4K random read / write (read / write ratio 1:1, simulating daily file operations); Queue depth: set QD1, QD2, and QD3 sequentially (test each queue depth separately); Test duration: 5 minutes for each QD value (to ensure data stability and avoid accidental fluctuations); File size: set to 100GB (greater than the SLC cache capacity of most SSDs, avoiding caching masking true performance); Tool selection: AS SSD Benchmark (custom queue depth function) for x86 platforms, and fio for ARM platforms (script parameters: --name=qd_test --ioengine=libaio --iodepth=1 --rw=randrw --rwmixread=50 --bs=4K --size=100G --runtime=300 --time_based; only the iodepth value needs to be modified for QD2 / QD3).

[0078] Data recording requirements: Each queue depth must record 5 metrics: "random read IOPS, average random read latency, random write IOPS, average random write latency, and throughput"; each QD value should be tested 3 times on the same platform, and the average value should be taken as the final data; when testing across platforms, it should be executed at the same time (e.g., within 30 minutes after initialization) to avoid changes in the empty disk status over time.

[0079] Execute after low queue depth testing, and clarify the steady-state judgment criteria: Preprocessing process: Tools and parameters: Use DiskSpd (x86 platform) or fio (ARM platform), and set "sequential read / write ratio 5:5, block size 64MB, IO depth 16, file size equal to the actual hard disk capacity, and loop count 3 times (covering 3 times the full disk capacity)"; Environment control: Close all unnecessary processes (such as browsers and document editors) during preprocessing, and monitor CPU usage through htop (Linux / ARM) or Task Manager (Windows) to ensure it does not exceed 15%; The test environment temperature is maintained at 20-25℃ and humidity at 40%-60% to avoid performance changes caused by temperature fluctuations.

[0080] Steady-state determination criteria: The fluctuation of the "average read / write speed of the entire disk" in two consecutive cycles is less than 3% (e.g., the average speed in the first cycle is 2200MB / s, and the second cycle is 2180MB / s, with a fluctuation of 0.9%), and the latency change is less than 5%, which is considered to have entered a steady state; if the standard is not met, one more cycle test is added until the requirements are met (no more than 5 cycles, to avoid excessive erasing and writing affecting the hard drive status).

[0081] Empty disk baseline record: After steady state, perform complete performance test (using the original test items in Chapter 2, supplemented with low queue depth data), integrate all performance indicators of "normal QD (1 / 8 / 32) + low QD (1 / 2 / 3)" and SMART data (consistent with the baseline after initialization) into "Empty Disk Steady State Baseline Report", and mark the number of preprocessing loops and steady state judgment results.

[0082] Figure 4 yes Figure 1 The flowchart for step 3 is as follows: Figure 4 As shown, step 3 includes: Step 301, creating typical application load models, including office models, content creation models, and game models; Step 302, using professional disk stress testing tools to accurately simulate the load models; Step 303, filling the dirty disk ratio of the solid-state drive to the target value through sequential or random writing, applying the corresponding load model during the writing of each capacity ratio; Step 304, continuously sampling performance at each dirty disk ratio point and recording performance data; Step 305, generating a performance degradation curve to observe whether the solid-state drive remains stable or experiences fluctuations and speed reduction under continuous pressure.

[0083] A load model closely mirroring real-world usage scenarios is constructed to accurately simulate load as the proportion of dirty drives gradually increases. Through continuous sampling and curve analysis, the performance stability of SSDs under different usage conditions is verified, supplementing the scenario-based dimension of existing dirty drive testing. For three core usage scenarios, the parameter definitions and scenario characteristics of the load model are clearly defined to ensure that the simulation results closely reflect real user behavior.

[0084] Office Model: Focuses on lightweight operations such as document processing, web browsing, and email sending and receiving, primarily involving random read and write of small files. The file size range is set to 4KB-100MB (with 4KB-16KB files accounting for 60%, matching the characteristics of office software caching and temporary files), the read-write ratio is 7:3 (read operations are more frequent, such as repeatedly opening documents and loading spreadsheets), the IO depth is 1-4 (low concurrency for single tasks, in line with the single-window operation habits in office work), and the average number of IO requests per second (IOPS) is controlled at 300-800, simulating the intermittent load characteristics of daily office work (every 10 minutes of continuous load, pause for 2 minutes to restore the office break).

[0085] Content creation model: Covering scenarios such as video editing, image design, and 3D modeling, balancing sequential read / write of large files and random access to small files—Large files (1GB-10GB, accounting for 40%) use sequential read / write (such as video export and material import), with a block size of 128MB and an IO depth of 8-16; Small files (16KB-100MB, accounting for 60%) use random read / write (such as loading layers in design software and calling texture files in 3D models), with a read / write ratio of 4:6 (more frequent write operations, such as continuously saving project files), maintaining IOPS at 1500-3000, and running continuously without interruption (matching the scenario of continuous work during creation).

[0086] Game Model: Simulates the entire process of game installation, update, and operation, distinguishing between two load phases: Installation / Update Phase: Sequential writing of large files (500MB-5GB, accounting for 70%), block size 64MB, IO depth 10-20, IOPS 2000-4000; Operation Phase: Random reading and writing of small files (4KB-64MB, accounting for 80%) (such as loading game maps, reading character data), read-write ratio 6:4, IO depth 3-8, cycling every 30 minutes with "10 minutes of high-load operation + 5 minutes of low-load standby" (reproducing the rhythm of game startup, play, and pause).

[0087] We selected cross-platform compatible professional tools and achieved accurate reproduction of the load model through fine-grained parameter configuration, avoiding simulation deviations caused by tool differences: Tool selection and cross-platform adaptation: For x86 platforms (AMD / Intel / next-generation), we prioritized DiskSpd (supports custom IO modes and load cycles) and CrystalDiskMark (aids in verifying single-scenario loads); for ARM platforms, we uniformly used fio (which supports deep parameter configuration through compilation to adapt to the ARM architecture). All tools were updated to the latest version to ensure support for next-generation hardware features such as NVMe 2.0 and PCIe 5.0.

[0088] Unified configuration of load parameters: Tool scripts were written for the three types of models, and the core parameters were clearly defined. For example, the DiskSpd script for the office model was set to "-b 4K -t 2 -o 2 -d 600 -r -w 30 -L" (block size 4K, 2 threads, IO depth 2, duration 10 minutes, random read / write, write ratio 30%, recording latency), and the fio script for the content creation model was set to "--name=content --ioengine=libaio --rw=randrw --rwmixread=40 --bsrange=16K-10G --size=500G --iodepth=12 --runtime=3600 --time_based" (random read / write, read ratio 40%, block size range 16K-10G, total data volume 500G, IO depth 12, duration 1 hour).

[0089] Load validity verification: Before each load test, use system monitoring tools (Task Manager for x86, htop+iotop for ARM) to confirm that the actual load parameters are consistent with the model design. For example, when the office model is running, the monitoring should show whether the 4K file IO ratio reaches 60% and whether the IOPS is in the range of 300-800. If the deviation exceeds 10%, the tool parameters need to be adjusted (such as increasing the number of threads or modifying the block size range), and the test should be repeated until it meets the model requirements.

[0090] The method of "gradual filling + real-time load" is adopted. As the proportion of dirty disks gradually increases, the corresponding scenario load is applied simultaneously to simulate the superposition state of "data accumulation + continuous use" in real use: Target dirty disk proportion setting: Continue the original test framework and select 4 typical proportions (30%, 50%, 70%, 90%). Calculate the amount of data to be filled for each proportion according to the actual capacity of the solid-state drive (e.g., for a 1TB hard drive, 30% corresponds to 300GB, and 90% corresponds to 900GB). Before filling, the initial empty disk status (100% unallocated space) is confirmed through disk management tools.

[0091] Filling method and load matching: The filling method is selected based on the characteristics of the load model—the office model and game operation phase mainly use "random writing" (filling small files of 4K-100MB, matching the high proportion of small files in the model), while the content creation model and game installation phase mainly use "sequential writing" (filling large files of 1GB-10GB, matching the large file read and write requirements in the model). During the filling process, "filling-load" synchronization is achieved through tool scripts: every time 10% of the total target amount is filled (e.g., 30% divided into 3 times, 100GB each time), filling is paused and the corresponding load model is started to run for 20 minutes, then filling continues until the target percentage is reached.

[0092] Fill rate control: Limit the fill rate using tool parameters (e.g., set fio to "--rate=100MB / s") to avoid excessively fast fill speeds that could cause momentary hard drive overload and affect the accuracy of load simulation; at the same time, record the fill time for each ratio. If the difference in fill time between two fills of the same ratio exceeds 8%, check for any performance abnormalities in the hard drive and rule out hardware malfunctions.

[0093] A multi-dimensional sampling mechanism is established at each dirty disk ratio point to ensure the integrity and timeliness of performance data, providing sufficient data support for subsequent curve generation: Sampling frequency and duration: Under each dirty disk ratio, performance data is sampled every 2 minutes during the load operation period, with each sample lasting 30 seconds (to avoid instantaneous fluctuations), and a total of 20 samples are taken for each ratio (covering a 20-minute load cycle); the sampling period includes the load operation peak (such as the large file export stage of the content creation model) and the stable period (such as the document idle stage of the office model), comprehensively capturing the performance under different load intensities.

[0094] Sampling metrics definition: In addition to the original tests of "continuous read / write speed, 4K random read / write IOPS, and average latency", new scenario-based metrics have been added: the office model focuses on recording "random read latency of 4K-16KB small files" (affecting document opening speed), the content creation model focuses on recording "sequential write speed of 128MB large files" (affecting video export efficiency), and the game model focuses on recording "random read / write throughput of 64MB files" (affecting map loading speed); all metrics retain 3 significant digits to avoid insufficient data precision.

[0095] Cross-platform synchronous sampling: During multi-platform testing, time synchronization tools (such as NTP service) are used to ensure that the sampling time of each platform is consistent (error less than 10 seconds). Under the same dirty disk ratio and the same load model, the number of samplings and the definition of indicators are exactly the same for each platform. The sampling data is stored in categories of "platform-dirty disk ratio-load model" (such as "ARM-50%-office model-performance data.txt"), and the sampling time, ambient temperature (20-25℃), and system resource utilization (CPU<20%, memory<40%, excluding interference from other resources) are marked.

[0096] The performance trend is presented by visualizing curves, and the stability of the solid-state drive under continuous pressure is determined by the fluctuation range, which is connected to the original performance analysis system. Curve generation specifications: Use Origin or Excel (cross-platform compatible) to draw curves. The horizontal axis is "dirty disk ratio (30% / 50% / 70% / 90%)", and the vertical axis is each core performance indicator (such as "4K random read IOPS" and "128MB sequential write speed"). The same indicator is drawn according to the load model (such as blue line for office model, red line for content creation model, and green line for game model). The specific value of each sampling point is marked on the curve, and error bars are added (reflecting the standard deviation of 20 samples).

[0097] Stability assessment criteria: Two criteria are established: First, under the same dirty disk ratio, the performance data fluctuation range (maximum value - minimum value) / average value of 20 samples is ≤15%, indicating stable performance at that ratio. Second, from a dirty disk ratio of 30% to 90%, the performance degradation range (initial value - final value) / initial value is ≤30%, indicating overall degradation is controllable. If a certain indicator fluctuates by more than 15% (e.g., IOPS fluctuation of 20% when the game model has 70% dirty disks), the fill and load tests at that ratio must be re-executed to eliminate accidental interference. If the degradation range exceeds 30%, it is necessary to analyze whether it is caused by hard drive hardware characteristics in conjunction with SMART data (such as erase count and bad block count).

[0098] Curve application integration: The generated "load-dirty disk-performance" curve is integrated into subsequent processes—in the "system resource contention tolerance test", it serves as a benchmark curve for scenarios without resource contention, comparing performance deviations when resource contention occurs; in the "machine learning performance prediction model construction", "load type" is added as an input feature to improve the adaptability of the prediction model to different usage scenarios, making the prediction results more in line with the actual user experience.

[0099] Figure 5 yes Figure 1 The flowchart for step 4 is as follows: Figure 5 As shown, step 4 includes: step 401, while running the solid-state drive performance benchmark test, start the CPU stress test, memory bandwidth test and GPU load test in the background; step 402, compare the difference in solid-state drive performance data under two conditions: system idle and system full load; step 403, evaluate the solid-state drive's tolerance to system resource contention and determine the consistency of solid-state drive performance data.

[0100] By constructing a dual-scenario comparison of "system idle - system full load", the performance degradation of solid-state drives under resource contention is quantified, their anti-interference ability and data stability are evaluated, and the test results are made to reflect the actual multi-tasking environment.

[0101] For both x86 (AMD / Intel / next-generation) and ARM platforms, separate stress test schemes were designed for CPU, memory, and GPU to ensure that the "full load" state conforms to the characteristics of real multi-tasking workloads.

[0102] CPU Stress Test: x86 Platform: Use Prime95 (Windows) or mPrime (Linux), select "Blend" mode (balancing computation and memory usage), and set the number of threads according to the number of CPU cores (e.g., 8 threads for an 8-core CPU) to keep the core utilization stable at 80%±5% (avoiding 100% utilization which could cause the system to become unresponsive); For newer x86 platforms (such as Intel 14th generation, AMD Ryzen 8000 series), CPU power-saving technology needs to be disabled (by setting "High Performance Mode" in the motherboard BIOS) to prevent load fluctuations.

[0103] ARM platform: Use the stress-ng tool to execute "stress-ng --cpu 4 --cpu-load 80 --cpu-method matrix" (4 threads, 80% load, matrix calculation stress mode). Monitor in real time with htop. If the load is below 75%, increase the number of threads (e.g., adjust to 6 threads) to ensure that the load intensity is consistent with the x86 platform.

[0104] Memory bandwidth test: x86 platform: Windows used AIDA64's "Memory and Cache Test" module, selecting the "Memory Bandwidth" test (continuous read and write memory, using 70%±5% of physical memory); Linux used the mbw tool, setting "mbw -t 4 -s 2G" (4 threads, test block size 2GB) to maintain memory bandwidth utilization at 60%-70% of the platform's peak (to avoid memory bandwidth saturation masking SSD performance differences).

[0105] ARM platform: Use the memtester tool to execute "memtester 8G 1" (test 8GB memory, 1 loop), along with "dd if= / dev / zero of= / dev / shm / test bs=1G count=6" (occupy 6GB shared memory) to ensure that the memory utilization is stable at around 70%. At the same time, use "perf stat -e mem_load_retired.l3_miss" to monitor memory latency and avoid abnormal fluctuations.

[0106] GPU load test: x86 platform: For discrete graphics cards, use the 3DMark “Time Spy” stress test (run in a loop, with GPU utilization maintained at 90%±5%). For integrated graphics cards, use the “Performance Test” module of Intel UHD Graphics Control Panel (Intel platform) or AMD Radeon Software (AMD platform), set to “Continuous Load Mode”, and ensure that GPU utilization is not lower than 85%.

[0107] ARM platform: For devices equipped with integrated GPUs (such as Rockchip RK3588 Mali-G610), use the glmark2 tool to execute "glmark2 --fullscreen --run-forever" (full-screen loop rendering, GPU load 80%±5%); for ARM platforms without a dedicated GPU, use the "gpu-burn" tool to simulate the load and ensure it matches the load level of the x86 platform.

[0108] Simultaneous multi-stress startup: A cross-platform startup script (batch script for Windows, shell script for Linux / ARM) is written to automatically start CPU, memory, and GPU stress tests within 10 seconds of SSD performance testing starting, avoiding time differences caused by manual operation; verification is performed using system monitoring tools (Task Manager for x86, htop+iotop+glxinfo for ARM) to ensure that all three types of stress reach the target load simultaneously (deviation ≤10%) before SSD performance sampling can begin.

[0109] First, define the scenario standards, then perform comparisons for the three types of application load models to ensure that data differences can be quantified:

[0110] Scenario Standard Definitions: System Idle: Close all unnecessary processes (such as antivirus software, background updates), CPU utilization ≤5%, memory utilization ≤30%, GPU utilization ≤10%, no other disk read / write operations (confirm SSD IO is 0 via iotop), and start testing after 5 minutes of stability. System Full Load: Start the three types of stress tests in step 401. After the CPU, memory, and GPU loads all reach the target values ​​and stabilize for 3 minutes, start the SSD performance test; if any resource load deviates from the target value by ±15% during the test (e.g., CPU drops from 80% to 60%), immediately pause the test, readjust the stress parameters, and retry.

[0111] Comparative Testing Process: For three load models—office, content creation, and gaming—two dual-scenario tests, "idle" and "full load," were performed: Idle Scenario Test: The test was run with the original load model parameters (e.g., 4K random read / write, IO depth 2 for the office model) for 20 minutes, sampling performance data every 2 minutes (10 times in total), and the average value was taken as the "idle baseline value." Full Load Scenario Test: After the stress test stabilized, the test was run with the exact same load model parameters (same tool, same IO depth, same test duration), sampling data every 2 minutes (10 times in total), and the average value was taken as the "full load test value." Difference Calculation: For each performance metric (e.g., 4K read latency for the office model, 128MB sequential write speed for the content creation model), the "difference rate = |(full load test value - idle baseline value) / idle baseline value| × 100%" was calculated, and the difference rate and fluctuation trend were recorded (e.g., whether the latency continuously increased under full load).

[0112] Key points of cross-scenario comparison:

[0113] Office Model: Focus on comparing the difference in "random read latency for small files (4K-16KB)" (affecting document opening speed). If the difference rate is >15%, it is necessary to investigate whether CPU pressure is causing IO scheduling latency. Content Creation Model: Focus on comparing the difference in "sequential write speed for large files (128MB)" (affecting video export efficiency). If the difference rate is >20%, it is necessary to check whether memory bandwidth has become a bottleneck (e.g., insufficient data caching due to memory pressure). Game Model: Focus on comparing the difference in "random read / write throughput for files (64MB)" (affecting map loading speed). If the difference rate is >18%, it is necessary to confirm whether GPU load is occupying PCIe bandwidth (e.g., resource contention when NVMe SSD and GPU share PCIe channels).

[0114] By combining the difference rate and repeated testing data, a two-dimensional evaluation system is established to ensure the objectivity and reliability of the results:

[0115] Tolerance assessment criteria: Setting thresholds for the difference rate among three load models (based on actual usage scenario requirements):

[0116] Office Model: If the difference rate of all performance indicators is ≤15%, it is judged as "Excellent Tolerance"; if the difference rate is 15% < ≤20%, it is judged as "Good Tolerance"; if the difference rate is >20%, it is judged as "Insufficient Tolerance" (users should be advised to avoid running high-load programs at the same time while working).

[0117] Content creation model: Difference rate ≤ 20% is "Excellent", 20% < difference rate ≤ 25% is "Good", > 25% is "Insufficient" (users should be advised to reduce background program usage during creation); Game model: Difference rate ≤ 18% is "Excellent", 18% < difference rate ≤ 23% is "Good", > 23% is "Insufficient" (users should be advised to close other high GPU load applications while playing games).

[0118] If the difference rate of a single indicator exceeds the standard under a certain model (e.g., the difference rate of sequential writing in the content creation model is 28%), further testing is required: turn off a certain type of pressure separately (e.g., turn off GPU load first) and observe whether the difference rate decreases, and locate the core resource that causes performance degradation (e.g., GPU usage of PCIe bandwidth).

[0119] For each scenario (idle / full load), repeat the same load model test 3 times, and calculate the "performance fluctuation value = |(single test value - 3 average values) / 3 average values| × 100%" for each test: if all 3 fluctuation values ​​are ≤5%, it is judged as "excellent consistency" (stable performance); if 1 fluctuation value is >5% but ≤8%, and the rest are ≤5%, it is judged as "good consistency"; if any fluctuation value is >8%, it is judged as "insufficient consistency", and the cause needs to be investigated (such as resource scheduling conflicts between stress testing tools and SSD testing tools, or performance throttling caused by excessive hardware temperature).

[0120] Meanwhile, compare the consistency differences between idle and full-load scenarios: if the fluctuation value is more than 3% higher under full load than under idle (e.g., 3% fluctuation under idle and 7% fluctuation under full load), it indicates that the competition for system resources has intensified the instability of SSD performance, and this should be specifically noted in the report.

[0121] Troubleshooting: If the difference rate is normal but the consistency is poor (e.g., difference rate of 12%, but fluctuation of 9% in 3 tests), the stability of the test environment needs to be checked (e.g., whether the power supply is insufficient, causing fluctuations in hardware power supply); if the difference rate exceeds the standard but the consistency is good (e.g., difference rate of 22%, fluctuation of only 2%), it means that the SSD is sensitive to this type of resource contention, but the performance degradation is predictable, and the scenario to be avoided should be clearly stated in the usage recommendations.

[0122] Data storage: Records are categorized by "Scenario (Idle / Full Load) - Load Model (Office / Content Creation / Game) - Platform (x86 / ARM)" and include "each sample value, average value, difference rate, and fluctuation value". The hardware temperature during the test is also noted (CPU / SSD / GPU must all be recorded to avoid the temperature >70℃ affecting the results).

[0123] Process Integration: "Idle / Full Load Difference Rate" and "Performance Consistency Results" are used as input features to supplement the machine learning prediction model (originally Chapter 5), such as "SSDs with a high difference rate under full load may experience more significant performance degradation after long-term use," thus improving the practicality of the prediction model. At the same time, a "Resource Competition Comparison Analysis Page" has been added to the PDF report (originally Chapter 6), which describes the performance differences under different scenarios in text (such as "In office scenarios, the 4K read latency increases by 12% under full load compared to idle, which is within an acceptable range") and provides targeted usage suggestions.

[0124] After step 402, the method further includes: step 404, performing SLC cache performance testing, including cache breakdown testing and cache recovery testing.

[0125] By constructing a dual-scenario comparison of "system idle - system full load," the performance degradation of SSDs under resource contention is quantified, and the breakdown threshold and recovery capability of SLC cache are evaluated simultaneously. This comprehensively covers the core performance dimensions of SSDs, ensuring that the test results closely reflect real-world multitasking environments. Addressing the key impact of SLC cache on actual SSD performance, two types of tests are conducted: "cache breakdown" and "cache recovery." Combining system idle / full load scenarios, the stability and self-healing capability of the cache under different loads are assessed.

[0126] The goal of the SLC cache breakdown test is to determine the actual capacity threshold of the SLC cache (i.e., the critical point at which performance drops from cache speed to NAND native speed after the continuous amount of data written exceeds the cache capacity), compare the threshold differences in idle / full load scenarios, and judge the impact of system resource contention on cache availability.

[0127] Execution steps: Test environment preparation: System idle scenario: Stabilize for 5 minutes according to the "idle standard" defined in step 402 (CPU≤5%, memory≤30%, GPU≤10%), and confirm that the SSD has no background read / write using iotop; System full load scenario: Start the CPU (80% load), memory (70% usage), and GPU (85%+ usage) stress test in step 401, stabilize for 3 minutes and start the test, ensuring that the stress parameters are completely consistent with those in step 402, and avoid interference from additional variables.

[0128] Testing tools and parameter configuration: fio is used uniformly across platforms (compatible with both ARM and x86). The script parameters are set as follows: "Sequential write (rw=write), block size 128MB (matching large file scenarios in content creation models), IO depth 8 (close to daily high-load write concurrency), file size set to 1.5 times the nominal capacity of the SSD (e.g., 1500GB for a 1TB SSD to ensure coverage of the cache + NAND native write stage), direct IO mode (--direct=1, avoiding system cache interference), real-time output speed (--per_job_logs=rate, recording instantaneous write speed every 10 seconds)".

[0129] Data Acquisition and Breakdown Determination: After starting the test, monitor the instantaneous write speed changes in real time: In the initial stage, the speed is stable at a high value (e.g., 3000MB / s, which is the SLC cache speed). When the speed drops sharply and stabilizes at a low value (e.g., 1200MB / s, which is the native TLC / QLC speed), record the cumulative write volume at this time, which is the "SLC cache breakdown threshold". Repeat the test 3 times for each scenario (idle / full load), and take the average of the 3 breakdown thresholds as the final result (if the deviation of a single test exceeds 10%, it is necessary to check whether the cache strategy is temporarily adjusted due to excessive temperature and retest); Compare the threshold difference between idle and full load scenarios: If the threshold under full load is more than 15% lower than that under idle (e.g., 20GB cache under idle, 17GB under full load), it indicates that the system resource contention has compressed the available capacity of the SLC cache, which needs to be highlighted in the subsequent tolerance assessment.

[0130] Special scenario adaptation: For SSDs with "dynamic SLC cache" (capacity changes with the proportion of dirty disks), the proportion of dirty disks must be fixed at 30% before testing (refer to the basic dirty disk proportion in step 303) to avoid the dirty disk status affecting the cache capacity determination; ARM platforms must ensure that the "speed monitoring" function of the NVMe / SATA controller is enabled during fio compilation, and some low-power ARM devices (such as Rockchip RK3568) need to disable CPU power saving to prevent write speed from being mistakenly judged as cache breakdown due to CPU downclocking.

[0131] The goal of the SLC cache recovery test is to evaluate the recovery speed under different system loads after SLC cache breakdown (i.e., the time and conditions required to recover from native NAND speed to cache speed) and verify the effectiveness of the SSD cache reclamation mechanism.

[0132] Execution Steps: Prerequisites: After completing the above cache breakdown test, maintain the current system state (idle / full load) and do not perform a safe erase (simulating the continuous use scenario after cache breakdown in actual use). Test Phase Division: Phase 1: No-Write Idle Recovery: After cache breakdown, immediately stop write operations and keep the system in the original scenario (idle / full load). Every 30 seconds, perform a "1GB small file sequential write" (parameters: --bs=128MB --size=1GB --rw=write --direct=1) via fio, and record the average speed of each write. When the write speed recovers to more than 90% of the initial cache speed for two consecutive times (e.g., initially 3000MB / s, recovering to more than 2700MB / s), record the total time from stopping writes to recovery, which is the "no-write recovery latency".

[0133] Phase 2: Low-load write recovery: After re-executing the cache breakdown test, do not stop writing, but reduce the write load to "low intensity" (parameters adjusted to: --bs=16MB --size=500GB --rw=write --direct=1 --rate=100MB / s, simulating daily scattered file writes); record the instantaneous write speed every 1 minute, observe the process of the speed recovering from the original value to the cache speed, and record the total time from adjusting to low load to recovery, which is the "low-load recovery latency".

[0134] Scenario Comparison and Anomaly Analysis: In idle scenarios, the write recovery latency should typically be ≤5 minutes (mainstream SSD cache reclamation efficiency), and the low-load recovery latency should be ≤8 minutes. If recovery does not occur within 10 minutes, it is necessary to check whether the SSD firmware has enabled the "Active Cache Reclamation" function (which can be confirmed through manufacturer tools, such as the "Performance Optimization" module in Samsung Magician). In full-load scenarios, if the recovery latency is more than 50% higher than that in idle scenarios (e.g., 3 minutes idle, 6 minutes full load), it indicates that system resource contention (e.g., low CPU scheduling priority, inability to release memory cache) has affected the SSD's cache reclamation efficiency, and it should be determined in the tolerance assessment as "cache recovery capability is significantly affected by load".

[0135] Resource competition tolerance and performance consistency assessment:

[0136] Based on the evaluation system in step 403, new criteria for judging SLC cache performance have been added: Excellent tolerance: In idle / full load scenarios, the difference in SLC cache breakdown threshold is ≤15%, and there is no write recovery latency of ≤8 minutes under full load and a recovery latency of ≤12 minutes under low load; Good tolerance: The difference in breakdown threshold is 15%-25%, or the full load recovery latency is 50%-80% higher than that under idle conditions; Insufficient tolerance: The difference in breakdown threshold is >25% (e.g., the cache capacity is only 70% of that under idle conditions under full load), or the recovery latency under full load is >15 minutes (cache performance cannot be quickly restored).

[0137] Figure 6 yes Figure 1 The flowchart for step 5 is as follows: Figure 6As shown, step 5 includes: Step 501, normalizing the collected performance data, which includes at least sequential read speed, random read speed, and latency; Step 502, assigning weights to each performance indicator based on the sensitivity of different application scenarios; Step 503, calculating the comprehensive performance consistency index based on the weights; Step 504, using machine learning algorithms, predicting the performance degradation trend of the solid-state drive under long-term use based on the performance degradation curve, the average number of erases and writes in the SMART data, and the number of bad blocks as input features; Step 505, integrating performance data, performance indicators, weights, and performance characteristics to generate a visualized digital profile.

[0138] By eliminating differences in metric magnitudes through data normalization and setting weights based on scenario sensitivity, a comprehensive performance consistency index is calculated to quantify the performance stability of SSDs under different usage conditions, providing a standardized data foundation for subsequent profiling and prediction. For the performance data collected in all the preceding test phases (empty / dirty disk, idle / full load, three application scenarios), a unified method is used to map metrics of different magnitudes to the 0-1 range, ensuring horizontal comparability between metrics.

[0139] Normalization method selection: Min-Max normalization is adopted (suitable for SSD performance data without extreme outliers). The formula is described in words as "Normalized value of a certain indicator = (Original test value of the indicator - Minimum value of the indicator in all test samples) / (Maximum value of the indicator in all test samples - Minimum value of the indicator)". If the indicator is of the "latency" type (the smaller the value, the better the performance), it is adjusted to "Normalized value = (Maximum value of the indicator - Original test value) / (Maximum value - Minimum value)" to ensure that all normalized indicators meet the unified logic of "the larger the value, the better the performance".

[0140] Core metrics coverage: Clearly define the metrics that must be included in the normalization. The mandatory metrics are "sequential read speed (MB / s), random read speed (4K QD1, MB / s), random read latency (4K QD1, ms), sequential write speed (MB / s), and random write IOPS (4KQD3)". Optional metrics can be added according to the scenario (e.g., add "128MB sequential write speed" for content creation scenarios and "64MB random read / write throughput" for gaming scenarios). The raw data for all metrics must be taken from the average of the three repeated tests mentioned above to avoid the influence of single data deviations on the normalization results.

[0141] Cross-platform data adaptation: Due to the differences in hardware fundamentals between x86 and ARM platforms (such as PCIe bandwidth and CPU scheduling efficiency), normalization needs to be performed separately for each platform. For example, the maximum value of "sequential read speed" for the x86 platform is taken from the highest value of all test samples on that platform, while the maximum and minimum values ​​for the ARM platform are calculated separately to prevent data distortion after normalization due to hardware differences between different platforms. After normalization, a three-dimensional data table of "platform-scenario-metric" needs to be generated (the text description structure is "x86 platform-office scenario-sequential read speed normalized value range 0.65-0.92"), and the data distribution range of each dimension should be marked.

[0142] Based on the sensitivity of user needs in different application scenarios, differentiated weights are assigned to the normalized indicators, with a total weight of 100%. The specific setting logic and basis are as follows:

[0143] Office scenario weighting: The core requirements are "fast document opening and smooth multitasking switching", so the weighting is as follows: "random read latency (30%, directly affecting document loading speed), random write IOPS (25%, affecting temporary file saving efficiency), sequential read speed (20%, affecting the opening of medium-sized files such as spreadsheets / PPTs), sequential write speed (15%, affecting file backup), and other auxiliary indicators (10%, such as SLC cache recovery speed)". The weighting is based on office user behavior statistics (more than 70% of daily operations are small file reads and writes, and latency sensitivity is higher than throughput).

[0144] Content creation scenario weighting: The core requirements are "fast export of large files and stable reading and writing of materials", and the weighting is as follows: "sequential write speed (35%, affecting video export time), 128MB sequential read speed (25%, affecting simultaneous loading of multiple materials), random write speed (15%, affecting real-time saving of project files), random read latency (15%, affecting layer switching), and others (10%)". The basis is the test data of content creation software (such as when Premiere exports a 10GB video, every 100MB / s increase in sequential write speed reduces the time by about 1.5 minutes).

[0145] Game scene weighting: The core requirements are "fast map loading and timely in-game data response", and the weighting is as follows: "4K random read IOPS (30%, affecting map texture loading), 64MB random read / write throughput (25%, affecting game save / load), sequential read speed (20%, affecting game installation and updates), random read latency (15%, affecting character action response), and others (10%)". The basis is the analysis of the runtime logs of mainstream 3A games (4K random read requests account for more than 80% during the map loading stage).

[0146] Weight Verification and Adjustment: The weight settings for each scenario need to be verified through "user satisfaction survey data"—for example, in an office scenario, if the user's satisfaction with "random read latency" has a positive correlation of more than 0.8 with the performance of this indicator (statistical correlation coefficient), then the weight of this indicator is confirmed to be reasonable; if after adjusting the weight of an indicator, the overall performance evaluation result deviates from the user's actual experience by more than 10%, then the weight allocation should be re-optimized (such as reducing the weight of sequential write speed and increasing the weight of random read latency).

[0147] Based on the "normalized index + scenario weight", the comprehensive performance value of SSD under different test conditions is calculated, and then the consistency index is obtained through difference analysis. The specific steps are as follows:

[0148] Single-scenario comprehensive performance value calculation: For a specific scenario (such as x86 platform - office scenario), the normalized values ​​of each indicator in the scenario are multiplied by their corresponding weights, and then summed to obtain the "single-scenario comprehensive performance value". The textual description of the calculation example is "Comprehensive performance value of a certain SSD in office scenario = (normalized value of random read latency × 30%) + (normalized value of random write IOPS × 25%) + (normalized value of sequential read speed × 20%) + ... + (other indicators × 10%)". The comprehensive value ranges from 0 to 1, and the closer the value is to 1, the better the performance in the scenario.

[0149] The core calculation logic of the consistency index focuses on evaluating two types of consistency: "different system loads under the same scenario" and "different dirty disk ratios under the same system load". System load consistency: Calculates the difference between the "overall performance value in idle scenarios" and the "overall performance value in full-load scenarios". The formula is described as "Load consistency index = 1 - |(full-load overall value - idle overall value) / idle overall value|". The closer the index is to 1, the smaller the impact of system load changes on performance. Dirty disk ratio consistency: Selects two key dirty disk ratios, 30% and 70%, and calculates the difference in the corresponding overall performance values. The formula is "Dirty disk consistency index = 1 - |(70% dirty disk overall value - 30% dirty disk overall value) / 30% dirty disk overall value|". The closer the index is to 1, the smaller the impact of increasing the dirty disk ratio on performance.

[0150] Overall consistency level determination: The average of the two consistency indices is taken as the "final overall performance consistency index". The determination criteria are: "≥0.85 is excellent (performance is minimally affected by load and dirty disk), 0.7-0.85 is good (impact is controllable), 0.55-0.7 is average (specific optimization of use cases is required), <0.55 is poor (insufficient performance stability)". If a single consistency index in a certain scenario is <0.6 (such as load consistency index 0.58, dirty disk consistency index 0.82), then the performance shortcomings of that scenario should be separately noted in the evaluation conclusion (such as "Insufficient performance stability when the system is fully loaded in the office scenario, it is recommended to reduce high-load background programs").

[0151] By optimizing the input feature dimensions and combining performance degradation patterns with SMART core health data, a more accurate long-term performance prediction model is constructed, which outputs the performance degradation trend of SSDs after 1 year, 3 years, and 5 years of use, providing a basis for users' lifecycle usage planning.

[0152] Based on step 504, “Performance Degradation Curve + SMART Data”, new key features are identified to form a multi-dimensional feature system:

[0153] Performance degradation curve features: Extract the core parameters of the "dirty disk ratio - performance" curve from the previous test, including "sequential read speed degradation rate from 30% to 90% dirty disk ratio, 4K random read latency growth rate, and SLC cache breakdown threshold decrease". Each parameter needs to be extracted separately according to the scenario (e.g., the degradation rate of office scenario and game scenario are used as separate features) to ensure that the features can reflect the degradation differences under different usage scenarios.

[0154] SMART Core Health Features: Focusing on parameters strongly correlated with long-term lifespan, the required features are "average erase / write cycles (calculated by dividing 'total erase cycles' in SMART by the total number of flash blocks), bad block growth (the increment of 'remapped sector count' during the test period), and the ratio of cumulative write volume (TBW) to nominal TBW". Optional features are added according to the SSD type (e.g., for SSDs without DRAM cache, add "host memory cache hit rate").

[0155] Feature preprocessing: Standardize all features (using the same method as in Chapter 5, ensuring consistent feature magnitude), and handle multicollinearity among features (e.g., use variance inflation factor (VIF) to filter and remove highly correlated features with VIF > 10, such as "cumulative write volume" and "average erase / write count". If the correlation is above 0.9, retain the more physically meaningful "average erase / write count".

[0156] To address the mixed characteristics of "temporal decay + health status", a combined model of "LSTM + Random Forest" is adopted, which balances the ability to capture time-series data and fuse multiple features.

[0157] Model division of labor: The LSTM neural network is responsible for processing time-series features such as "performance degradation curves". Its input is "performance values ​​of 5 key nodes with dirty disk ratios ranging from 30% to 90%", and its output is "predicted short-term (1-year) performance degradation rate". The random forest regression model is responsible for integrating "SMART health features + LSTM short-term prediction results". Its input is "average number of erases and writes, bad block growth, and 1-year degradation rate", and its output is "predicted medium-term (3-year) and long-term (5-year) performance degradation rate".

[0158] Training process control: The data is divided into a 70% training set, 15% validation set, and 15% test set. The training set must cover SSD samples from different brands (Samsung, Intel, Kioxia, etc.) and different types (TLC / QLC, with / without DRAM) to avoid model overfitting. When training the LSTM model, the settings are "64 hidden layer nodes, 50 iterations, and 0.001 learning rate". The settings for the random forest model are "100 decision trees and a maximum depth of 10". Hyperparameters are adjusted in real time using the validation set (e.g., stopping iteration when the validation set RMSE increases).

[0159] Model evaluation criteria: The mean absolute error (MAE) and coefficient of determination (R²) are used to evaluate the model accuracy. The test set requires "1-year decay rate prediction MAE ≤ 3%, 3-year MAE ≤ 5%, 5-year MAE ≤ 8%", and R² ≥ 0.85. If the requirements are not met, more samples (such as adding long-term decay data of QLC SSD) should be added and the model should be retrained. The prediction results should output "predicted value ± error range" (such as "3-year sequential read rate decay rate 18% ± 2%)" to improve the reliability of the results.

[0160] Based on the performance requirements of different application scenarios, the prediction results are translated into user-understandable usage suggestions: Office scenario: If the predicted random read latency increase is ≤10% over 3 years, it is recommended that "it can be used for office scenarios for a long time without the need for replacement in advance"; if the increase is ≥15%, it is recommended that "focus on document loading speed after 2 years and perform data migration if necessary"; Content creation scenario: If the sequential write speed decreases by ≥20% over 3 years, it is suggested that "exporting a 10GB video will take about 3 minutes longer after 3 years, and it is recommended that high-load users replace it after 2 years"; Gaming scenario: If the 4K random read IOPS decreases by ≤25% over 5 years, it means that "it can meet the loading requirements of mainstream games within 5 years"; if the decrease is ≥30%, it is recommended that "avoid running AAA games that are sensitive to loading speed after 4 years".

[0161] By integrating all the test data from the previous sections (performance, consistency, health, and prediction), a multi-dimensional visual digital profile is constructed to present the overall performance of the SSD in an intuitive way, reducing the barrier to interpretation for users. The profile clearly includes four primary dimensions, each with several secondary indicators. All indicator data comes from the test and calculation results from the previous sections: Performance Dimension: The secondary indicators are "normalized core indicator values ​​for each scenario" (random read latency in office scenarios, sequential write speed in content creation scenarios, etc.), reflecting the SSD's performance strength in different scenarios; Consistency Dimension: The secondary indicators are "load consistency index, dirty disk consistency index, and final overall consistency index," reflecting performance stability; Health Dimension: The secondary indicators are "current bad block count, cumulative write / erase cycles, remaining lifetime percentage (based on TBW), and SLC cache breakdown threshold," reflecting the hardware health status; Prediction Dimension: The secondary indicators are "1-year / 3-year / 5-year performance degradation rate and recommended replacement cycle," reflecting long-term usage prospects.

[0162] The system employs a combination of multiple charts and textual interpretations. All charts are created using cross-platform tools (Python Matplotlib, Origin) to ensure clarity (300dpi resolution) and aesthetics. Performance visualization is presented using radar charts, with 0 at the center and 1 (normalized maximum value) at the outer edge. Each axis corresponds to a core metric for a specific scenario (e.g., "Office - Random Read Latency," "Creative Work - Sequential Write Speed," "Gaming - 4K Read IOPS"). Different scenarios are marked with different colored lines (blue for office, red for creative work, and green for gaming). The inner circle of the radar chart is marked with "performance level lines" (0.7 for good and 0.85 for excellent), allowing users to intuitively judge that "a certain SSD's office scenario radar chart is close to the excellent line, while the gaming scenario is slightly below the good line."

[0163] Consistency dimension visualization: presented using a bar chart, with the horizontal axis representing "load consistency, dirty disk consistency, and overall consistency", and the vertical axis representing the exponential value (0-1). The bar chart colors are distinguished by level (excellent green, good yellow, average orange, and poor red). Specific values ​​are marked above the bars (e.g., "overall consistency 0.82"). An "industry average level" reference line (e.g., 0.75) is also added for easy comparison by users.

[0164] Visualization of Health and Predictive Dimensions: Presented using a "dual-axis line chart". The main vertical axis is "number of bad blocks / number of erases and writes" (left side), the secondary vertical axis is "performance degradation rate" (right side), and the horizontal axis is "usage time (years)". The solid line represents "actual test health data" (first 6 months), and the dashed line represents "model prediction data" (1-5 years). The chart is marked with "suggested replacement time point" (e.g., "4.5 years"), and the prediction error range is marked with shaded areas.

[0165] Comprehensive Summary Module: Add a "Core Conclusion" text box at the end of the profile, summarizing the SSD's performance in 3-5 sentences (e.g., "This SSD performs excellently in office scenarios, with a comprehensive consistency index of 0.86 and a 15% performance degradation rate over 3 years. It is recommended for office users to use it long-term, while content creators can use it for 2 years before evaluating and replacing it"), extracting key information.

[0166] Figure 7 yes Figure 1 The flowchart for step 6 is as follows: Figure 7 As shown, step 6 includes: step 601, automatically and securely erasing the solid-state drive after the test; step 602, generating a detailed PDF report containing all test data, curves, charts, consistency indices, and profiles; and step 603, providing corresponding recommendation indices based on the needs of different application scenarios.

[0167] After testing, the SSD is automatically and securely erased (ensuring data zeroing and reusability), generating a structured PDF report covering the entire testing process. Combined with multi-dimensional test results, quantitative recommendation indices are output for different application scenarios, forming a complete closed loop of "testing-evaluation-recommendation".

[0168] After all testing phases (including performance evaluation, predictive modeling, and profile generation) are completed, a secure erase is triggered via an automated script to ensure the hard drive is restored to its initial usable state, while avoiding errors from manual operation.

[0169] Automatic triggering mechanism design: The secure erasure script is bound to the test process, and the trigger condition is set to "the script will start automatically after the visualization of the digital profile in Chapter 7 is completed and the first draft of the report is exported". On Windows systems, the script is executed through Task Scheduler, and on Linux / ARM systems, it is scheduled to be triggered by cron (executed within 30 minutes after the test ends, allowing time for report verification). Before the script starts, a prompt window should pop up (or logs should be output) to confirm that "no other processes are occupying the solid-state drive" (such as the report generation tool being closed) to avoid data conflicts during erasure.

[0170] Cross-platform erasure tool and parameter adaptation: x86 platform (AMD / Intel / next generation): For SATA hard drives, prioritize calling the manufacturer's command-line interface (such as Samsung Magician's MagicianCLI --secureerase / dev / sda). For NVMe hard drives, use the nvme format command (parameter set to "--ses=1", i.e., secure erasure mode, erasure type selected as "user data erasure", retain firmware and SMART basic information); before erasure, the hard drive password protection must be automatically removed via script (if set in the test) to avoid erasure failure. ARM Platform: For SATA hard drives, use the hdparm tool (execute the script "hdparm --security-erase-enhanced user / dev / sda", and the temporary password "user" needs to be automatically set in advance via the script). For NVMe hard drives, use nvme format / dev / nvme0n1 --ses=1, but ensure that the ARM system has the ARM64 compiled version of nvme-cli installed (to avoid command incompatibility). For low-power ARM devices (such as Rockchip RK3588), add the pre-command "disable CPU power saving mode" (echo performance> / sys / devices / system / cpu / cpu0 / cpufreq / scaling_governor) to the script to prevent the CPU from downclocking during the erasure process, which would cause the speed to be too slow.

[0171] Erasure effect verification: After erasure is completed, the script automatically calls smartctl (cross-platform) to read SMART data and verify whether the "cumulative write volume" has returned to the baseline before the test (deviation ≤5%, allowing a small amount of write volume generated by the erase operation) and whether there is any new addition to the "remapped sector count"; at the same time, the script reads the first 1GB of data on the hard drive using the dd command (dd if= / dev / sdaof= / tmp / test.bin bs=1G count=1) to check whether the data is all 0 (or conforms to the manufacturer's default zeroing rule). If the verification fails, the script automatically retryes the erase (up to 3 times) and records the failure log (including time and error code) for subsequent troubleshooting.

[0172] Based on all the test data mentioned above (configuration information, performance data, consistency index, prediction results, and digital profiles), a structured PDF report is generated using automated tools to ensure the information is complete and traceable.

[0173] The report's core structure is designed as follows: It adopts a "general-specific-general" logic, consisting of eight chapters. The content of each chapter corresponds one-to-one with the preceding test sections. The specific structure is as follows:

[0174] Cover and Table of Contents: The cover includes "Test Report Number (format: SSD - Test Date - Platform Type, such as SSD-20251112-x86), Hard Drive Model to be Tested, Test Period, and Testing Organization"; the table of contents automatically generates page numbers for each chapter and supports internal jumping within the PDF (e.g., clicking "Chapter 5 Performance Data Standardization Processing" will jump to the corresponding page).

[0175] Test Overview: Briefly describe the test objectives (e.g., "Evaluate the performance and long-term stability of a certain NVMe SSD in office / creation / gaming scenarios"), test platform information (CPU, memory, and motherboard models for x86 / ARM platforms), list of test tools (including version numbers, such as fio 3.36 and CrystalDiskInfo 9.2.1), and test environment parameters (temperature 20-25℃, humidity 40%-60%, power supply 750W).

[0176] Hardware Configuration and SMART Baseline: Presents the configuration information collected in steps 101-102, such as "firmware version, controller model, NAND type, DRAM cache", and attaches a SMART baseline data table (including attribute ID, name, original value, and threshold), and marks the empty disk status confirmation result.

[0177] Test data for each stage: presented in the order of testing: "Initialization data (full disk write time, secure erase results), empty disk performance (low QD test value, steady-state baseline value), dirty disk degradation data (performance sample values ​​at each ratio, SLC cache breakdown threshold and recovery latency), resource contention data (idle / full load performance difference rate, consistency index)". Each data module is accompanied by a corresponding chart (such as a dirty disk performance degradation line chart, an SLC cache recovery trend chart). The data source is indicated below the chart (e.g., "Data is taken from the average of 3 repeated tests, test time 2025-11-10 09:00-11:30").

[0178] Performance standardization and consistency assessment: presents the "normalized data table (platform-scenario-indicator three-dimensional data), scenario-based weight allocation table, and comprehensive consistency index calculation process and results" in Chapter 5, with the basis for determining the consistency level (e.g., "comprehensive consistency index 0.83, judged as good").

[0179] Long-term performance prediction: Presents the “List of input features for the prediction model, predicted performance degradation rates for 1 year / 3 years / 5 years (including ± error range), and scenario-based usage suggestions” in Chapter 6, with a biaxial line graph of the prediction trend (marking the connection points between actual test data and prediction data).

[0180] Visualized digital profile: Fully embedded in Chapter 7's "Performance Radar Chart, Consistency Bar Chart, and Health and Prediction Dual-Axis Chart", accompanied by a profile interpretation guide (such as "the blue lines in the radar chart represent the office scene, and the closer to the periphery, the better the performance"), with core conclusion text boxes.

[0181] Test conclusions and recommendations: Summarize the hard drive's core advantages (such as "low random read latency and excellent consistency in office scenarios") and shortcomings (such as "long SLC cache recovery latency under full load"), and give reuse suggestions (such as "it can be used for subsequent similar tests after erasure, and it is recommended to recalibrate the SMART baseline after every 10 tests").

[0182] Automatic Generation and Verification: Tool Selection: For Windows platforms, the Python ReportLab library (supports dynamic insertion of charts and tables) is used; for Linux / ARM platforms, JasperReports (called via Java script, adapted for ARM64 architecture) is used. The script predefines the report template (including font style, chart size, and page margins) to ensure consistent report format across different platforms (A4 paper, 11-point Song font for body text, 14-point Hei font for titles). Data Integration: The script reads structured data files generated from previous tests (such as CSV format performance data, PNG format charts, and TXT format consistency indices) and automatically fills them into the corresponding positions in the report template, eliminating the need for manual entry. For example, in the "dirty disk decay data" module, the script reads the performance values ​​for 30% / 50% / 70% / 90% percentages from "dirty_disk_perf.csv", automatically generates line charts, and inserts them into the report. Report Verification: After generation, the script automatically performs two verifications: first, data integrity verification (checking whether there is missing data in each section, such as whether the "SMART baseline table contains the cumulative write volume"), and second, chart clarity verification (confirming that the chart resolution is ≥300dpi and that the text annotations do not overlap). If the verification passes, the final PDF report is output to the specified path (such as "D:\SSD_Test_Reports\20251112"). If the verification fails, an error log is output (such as "Missing SLC cache recovery test data, report generation interrupted").

[0183] Based on full-scale test data (performance, consistency, predicted degradation), a quantitative recommendation index (1-10 points, with higher scores indicating higher recommendation intensity) is calculated for three core scenarios: office work, content creation, and gaming. The recommendation levels and usage suggestions are clearly defined: Recommendation Index Scoring Dimensions and Weights: The recommendation index for each scenario consists of 3 core dimensions with a total weight of 100%. The dimension settings are based on scenario-specific sensitivity, as detailed below:

[0184] Office Scenario: The core dimensions are "Random Read Latency Normalized Value (40%, reflecting document loading speed), Load Consistency Index (35%, reflecting performance stability under multi-tasking), and 3-Year Random Read Latency Attenuation Rate (25%, reflecting long-term user experience)". For example, for a certain SSD in an office scenario, "Random Read Latency Normalized Value is 0.85 (40% weight, score 34), Load Consistency Index is 0.82 (35% weight, score 28.7), and 3-Year Attenuation Rate is 8% (25% weight, score 22.5)", so the total recommendation index = 34 + 28.7 + 22.5 = 85.2 → converted to 8.5 out of 10.

[0185] Content creation scenario: The core dimensions are "128MB sequential write speed normalized value (45%, reflecting video export efficiency), SLC cache breakdown threshold (30%, reflecting large file continuous write capability), and 3-year sequential write speed decay rate (25%, reflecting long-term creation efficiency)". If a certain SSD has "sequential write normalized value of 0.78 (45% weight score of 35.1), cache threshold of 20GB (30% weight score of 27), and 3-year decay rate of 15% (25% weight score of 21.25)", the total recommendation index = 35.1 + 27 + 21.25 = 83.35 → 8.3 out of 10.

[0186] Game Scenarios: The core dimensions are "4K random read IOPS normalized value (40%, reflecting map loading speed), dirty disk consistency index (30%, reflecting game save / load stability), and 5-year 4K read IOPS decay rate (30%, reflecting long-term game experience)". If a certain SSD has "4K IOPS normalized value 0.8 (40% weight, score 32), dirty disk consistency 0.79 (30% weight, score 23.7), and 5-year decay rate 22% (30% weight, score 23.4)", the total recommendation index = 32 + 23.7 + 23.4 = 79.1 → 7.9 out of 10.

[0187] Recommendation levels and usage suggestions: Based on a 10-point recommendation index, we are divided into 3 levels, each with specific scenario adaptation suggestions:

[0188] Highly recommended (8-10 points): Excellent performance, stability, and long-term degradation, suitable for high-load use in this scenario; for example, in office scenarios (8.5 points), it is recommended that "it can be used for daily office work in enterprises, supporting multiple users to process documents and spreadsheets simultaneously without worrying about performance fluctuations"; in creative scenarios (8.3 points), it is recommended that "it is suitable for professional video editing and 3D modeling, can smoothly export 4K videos, and does not need to be replaced within 3 years"; in gaming scenarios (7.9 points), it is recommended that "it is suitable for mainstream 3A game players, with fast map loading speed and can maintain a good gaming experience within 5 years".

[0189] General Recommendation (5-8 points): Core performance meets requirements, but there is a weakness in one aspect, suitable for light use in certain scenarios; for example, for office scenarios, 6.5 points (load consistency 0.68) is recommended to "suitable for personal office work, avoid running multiple high-load programs at the same time (such as video conferencing + document download)"; for creative scenarios, 6.2 points (SLC cache 10GB) is recommended to "suitable for short video creation (single video ≤10GB), not recommended for processing very large project files"; for gaming scenarios, 5.8 points (28% degradation over 5 years) is recommended to "suitable for light gamers, after 3 years it is recommended to reduce game graphics settings to improve loading speed".

[0190] Not recommended (1-5 points): The core dimensions do not meet the basic requirements of the scenario and are prone to performance bottlenecks; for example, in the office scenario (4.2 points, 20% latency decay over 3 years), it is recommended that "it is not recommended to use it for office work for a long time, and document loading may become sluggish after 1 year"; in the creative scenario (4.5 points, 0.45 normalized value for sequential write), it is recommended that "it should be avoided for video export, but can be used temporarily for material storage"; in the gaming scenario (3.9 points, low 4K IOPS), it is recommended that "it is not suitable for running large games, and can only be used for small games or game installation disks".

[0191] Recommendation index presentation method: A new "scenario-based recommendation page" has been added after the "Test Conclusions and Recommendations" section of the PDF report. It uses text to describe the "recommendation index, score details (scores of each dimension), recommendation level, and usage suggestions" for each scenario. At the same time, a bar chart is used to visually display the comparison of the recommendation index of the three scenarios (the horizontal axis is the scenario, the vertical axis is the 10-point index, and the bar chart color is distinguished by the level: strongly recommended green, generally recommended yellow, and not recommended red), so that users can quickly determine the scenario suitability of the hard drive.

[0192] A second embodiment is proposed based on the first embodiment. In the second embodiment,

[0193] Step 1: Pre-test In-depth Parameter Acquisition: Use a solid-state drive fingerprint acquisition tool to obtain the fingerprint information of the solid-state drive under test, recording the firmware version as "01.00.05", the controller model as "SM2260X", the NAND flash type as "QLC", the DRAM cache size as 8GB, and the simulated SLC caching strategy as "Write-back". Use a solid-state drive SMART data acquisition tool to fully record all readable SMART attribute values ​​in an empty disk state, including "Raw_Read_Error_Rate", "Thermal_Event_Count", and "Error_Log_Address".

[0194] Step 2, Enhanced Empty Disk Benchmark Test: In addition to the existing Intel platform, Apple Silicon Mac platforms and Intel Ultra platforms are added. Using a solid-state drive (SSD) testing tool, a full sequential write operation is performed to write data to 100% of the SSD's capacity, followed by a secure erase operation. Using an SSD performance testing tool, random read / write performance tests are conducted at QD1-QD3 levels for 30 seconds, with performance data collected every 5 seconds. Using an SSD steady-state testing tool, a 30-minute steady-state pre-condition test is performed to ensure the SSD remains stable throughout the test.

[0195] Step 3: Preparation of Dirty Disk Environment and Performance Degradation Curve Mapping under Dynamic Load: Create typical application load models, including an "Office Model," a "Content Creation Model," and a "Game Model." Use the disk stress testing tool FIO to simulate random writes for the "Office Model," sequential writes for the "Content Creation Model," and random reads for the "Game Model." Apply the corresponding load models at three target capacity percentages: 30%, 70%, and 100%. Continuously sample performance at each dirty disk percentage point for 30 minutes with a 5-minute interval. Generate a performance degradation curve based on the sampled data to observe whether the SSD remains stable or experiences fluctuations and slowdowns under continuous stress.

[0196] Step 4: System-level stress tolerance and consistency testing: While running SSD performance benchmark tests, launch the Prime95 stress test tool, AIDA64 bandwidth test tool, and CUDA-Z GPU load test tool in the background. Compare the differences in SSD performance data under two conditions: system idle and system full load. Perform SLC cache performance testing. First, perform continuous large file write operations. When the amount of data written reaches the SLC cache capacity, perform a cache breakdown test. Then, after 30 minutes of cache recovery, perform small file write tests. Evaluate the SSD's tolerance to system resource contention and determine performance consistency.

[0197] Step 5: Intelligent Data Analysis and Performance Profile Generation: The collected performance data, including sequential read speed, random read speed, and latency, is normalized. Weights are assigned to each performance metric: sequential read speed (0.3), random read speed (0.4), and latency (0.3). A comprehensive performance consistency index is calculated based on these weights. Using a linear regression algorithm, a model is built based on the performance degradation curve and SMART data changes to predict the SSD's performance after writing 1TB of data. A visual digital profile is generated, using a radar chart to display the scores for "empty disk performance," "half-disk performance," and "full disk performance."

[0198] Step 6: Automatic Post-Test Diagnosis and Report Generation: Execute the SSD secure erase command to restore the SSD to its initial state. Generate a detailed PDF report containing test data, curves, charts, and performance profiles. Provide targeted recommendation indices based on different application scenarios; for example, for gaming scenarios, it is recommended to select an SSD product with a "gaming model".

[0199] A third embodiment is proposed based on the first embodiment. In the third embodiment,

[0200] Step 1: Pre-test In-depth Parameter Acquisition: Use a solid-state drive fingerprint acquisition tool to obtain the fingerprint information of the solid-state drive under test, recording the firmware version as "02.00.03", the controller model as "PM9818", the NAND flash type as "TLC", the DRAM cache size as 16GB, and the simulated SLC caching strategy as "Write-through". Use a solid-state drive SMART data acquisition tool to fully record all readable SMART attribute values ​​in an empty disk state, including "Temperature_Celsius", "Power_On_Hours", and "Host_Read_Commands".

[0201] Step 2, Enhanced Empty Disk Benchmark Test: In addition to the existing AMD platform, an Apple Silicon Mac platform and an AMD Ryzen AI platform are added. Using an SSD testing tool, a full sequential write operation is performed, writing data to 50% of the SSD's capacity, followed by a secure erase operation. Using an SSD performance testing tool, random read / write performance tests are conducted at QD1-QD3 levels for 60 seconds, with performance data collected every 10 seconds. Using an SSD steady-state testing tool, a 60-minute steady-state pre-condition test is performed to ensure the SSD remains stable throughout the test.

[0202] Step 3: Preparation of Dirty Disk Environment and Performance Degradation Curve Mapping under Dynamic Load: Create typical application load models, including an "Office Model," a "Content Creation Model," and a "Game Model." Use the disk stress testing tool FIO to simulate random reads for the "Office Model," sequential writes for the "Content Creation Model," and random writes for the "Game Model." Apply the corresponding load models at three target capacity percentages: 20%, 50%, and 80%. Continuously sample performance at each dirty disk percentage point for 45 minutes with a 15-minute interval. Generate a performance degradation curve based on the sampled data to observe whether the SSD remains stable or experiences fluctuations and slowdowns under continuous stress.

[0203] Step 4: System-level stress tolerance and consistency testing: While running SSD performance benchmark tests, launch the Prime95 stress test tool, AIDA64 bandwidth test tool, and CUDA-Z GPU load test tool in the background. Compare the differences in SSD performance data under two conditions: system idle and system full load. Perform SLC cache performance testing, first performing continuous small file write operations, and then performing a cache breakdown test when the amount of data written reaches the SLC cache capacity. Subsequently, after 15 minutes of cache recovery, perform a large file read test. Evaluate the SSD's tolerance to system resource contention and determine performance consistency.

[0204] Step 5: Intelligent Data Analysis and Performance Profile Generation: The collected performance data, including sequential read speed, random read speed, and latency, is normalized. Weights are assigned to each performance metric: sequential read speed (0.35), random read speed (0.45), and latency (0.2). A comprehensive performance consistency index is calculated based on these weights. Using time-series analysis algorithms, a model is built based on performance degradation curves and SMART data changes to predict the SSD's performance after writing 10TB of data. A visual digital profile is generated, using a Kiviat chart to display the scoring results for "empty disk performance," "half-disk performance," and "full disk performance."

[0205] Step 6: Automatic Post-Test Diagnosis and Report Generation: Execute the SSD secure erase command to restore the SSD to its initial state. Generate a detailed PDF report containing test data, curves, charts, and performance profiles. Provide targeted recommendation indices based on different application scenarios; for example, for content creation scenarios, it is recommended to choose an SSD product with the "Content Creation Model".

[0206] A fourth embodiment is proposed based on the first embodiment. In the fourth embodiment,

[0207] Step 1, Pre-test In-depth Parameter Collection: Hardware Configuration Information Collection: Use command-line tools (such as smartctl) and manufacturer-specific tools to obtain the hardware configuration information of the SSD under test. Detailed records:

[0208] Firmware version: SAFA12.3; Controller model: Phison PS5021-E21T; NAND flash memory type: 3D TLC; DRAM cache: Yes, capacity 2GB LPDDR4; Simulated SLC cache strategy: Dynamic cache, estimated capacity approximately 150GB.

[0209] Step 102, SMART Data Baseline Recording: With the disk empty, use the command `smartctl -a / dev / nvme0n1` to completely record the original values ​​of all SMART attributes, paying particular attention to:

[0210] Percentage Used: 0%

[0211] Data Units Written: 0

[0212] Media and Data Integrity Errors: 0

[0213] Temperature: 35°C

[0214] (Purpose: To provide a baseline for comparison of losses and error growth during subsequent testing)

[0215] Step 2, Enhanced Empty Disk Benchmark Test: Multi-Platform Preparation: The test will be conducted on the following two platforms:

[0216] Platform A (x86): Intel Core i7-13700K CPU, Z790 chipset, PCIe 4.0 x4 interface.

[0217] Platform B (ARM): Apple MacBook Pro with M2 Max chip, PCIe 4.0 x4 interface.

[0218] SSD initialization: On platform A, use the nvme format command to perform a secure erase on the SSD to ensure it is in a "fresh from the factory" state.

[0219] Low queue depth benchmark test: In the initial empty disk state, use the FIO (Flexible I / OTester) tool to test the following scenarios on platforms A and B respectively. Each test runs for 60 seconds, with a 10-second warm-up period, and the average value is taken:

[0220] Random read / write (4KB):

[0221] fio --name=qd1_randread --ioengine=libaio --rw=randread --bs=4k --numjobs=1 --iodepth=1 ...

[0222] fio --name=qd1_randwrite --ioengine=libaio --rw=randwrite --bs=4k --numjobs=1 --iodepth=1 ...

[0223] (The same tests were conducted on QD2 and QD3.)

[0224] Sequential read / write (128KB): Performance test under QD1 and QD32.

[0225] (Objective: To obtain the performance benchmark of SSDs on two platforms under ideal conditions, for subsequent calculation of performance consistency degradation rate)

[0226] Empty disk steady-state confirmation: With the disk empty, run a random write load (4KB, QD32) for 30 minutes and observe the performance curve. When the fluctuation range of read / write operations per second (IOPS) in the last 5 minutes is less than ±5%, it is determined that a steady state has been reached, and this steady-state performance is recorded.

[0227] Step 3: Preparation of dirty disk environment under dynamic load and plotting of performance degradation curves

[0228] Define a content creation workload model: Use the hybrid workload defined in the FIO configuration file to simulate video editing behaviors (such as proxy file generation):

[0229] rw = randrw (random read / write mixed)

[0230] rwmixread=70 (70% of operations are read)

[0231] bsrange=4k-64k (block size varies between 4KB and 64KB)

[0232] iodepth=16

[0233] Phased preparation and testing of visceral plaques:

[0234] To prepare a 30% dirty disk: First, fill the SSD to 30% capacity (approximately 300GB) using sequential writes.

[0235] 30% Dirty Disk Performance Test: Immediately apply the "Content Creation Load Model" defined in step 301 and test continuously for 30 minutes, recording IOPS and latency data every minute.

[0236] Prepare a 70% dirty disk: Continue writing data to 70% capacity (approximately 700GB).

[0237] 70% dirty disk performance test: Apply the same "content creation load model" for 30 minutes and record the data.

[0238] Prepare a 95% dirty disk (reserve 5% space to avoid the extreme case of being completely filled): Write data to 95% capacity.

[0239] 95% Dirty Disk Performance Test: Apply the same load, test for 30 minutes and record the results.

[0240] Step 303: Generate performance degradation curve: Normalize the IOPS data measured on platform A and platform B respectively relative to the respective empty disk baseline performance measured in step 203 (for example, empty disk IOPS is 100%), and plot it as a "dirty disk ratio - performance retention rate" curve.

[0241] Step 4: System-level pressure tolerance and consistency testing

[0242] System resource contention test: On platform A, when the SSD is at 50% dirty disk ratio and the "Content Creation Load Model" is running:

[0243] Simultaneously run Prime95 to perform a CPU stress test (select "Small FFTs" mode).

[0244] Simultaneously run FurMark to perform GPU stress testing.

[0245] Compare the SSD's IOPS and latency data when the system is idle and when the system is fully loaded (CPU + GPU).

[0246] SLC cache consistency test:

[0247] Cache breakdown test: In an empty disk state, initiate continuous sequential writes (1MB block size) and record the write speed. When the write speed suddenly drops from an initial high speed (e.g., 2000MB / s) to a stable value (e.g., 500MB / s), it is determined that the SLC cache is exhausted. Record the amount of data at the breakdown point (e.g., 180GB) and compare it with the 150GB estimated in step 101.

[0248] Cache recovery test: After cache breakdown, keep the SSD idle for 30 minutes. Then, perform a short (1 minute) sequential write test again to observe whether the speed recovers to the initial high speed, in order to evaluate the cache reclamation capability.

[0249] Step 5: Intelligent Data Analysis and Performance Profile Generation

[0250] Data normalization and weight allocation: For the "content creation scenario," weights are assigned to each performance metric.

[0251] Sequential write speed (weight 0.3): Affects the speed of saving large files.

[0252] 4K random read IOPS (weight 0.4): Affects the preview and loading speed of the media library.

[0253] Read / write latency (99th percentile) (weight 0.3): affects real-time operation performance.

[0254] Computational Performance Conformity Index (PCI):

[0255] Formula: PCI = (Performance_30% × W1 + Performance_70% × W2 + Performance_95% × W3) / (W1 + W2 + W3)

[0256] Among them, performance_X% is the weighted performance score under the X% dirty disk ratio; W1, W2, W3 are the importance weights of different dirty disk ratios (for example, 70% dirty disks have the highest weight).

[0257] Performance Prediction Model: A simple linear regression model is used as an example. Using "95% dirty drive performance retention rate" in short-term testing as the independent variable (X), and "performance retention rate after writing 1PB of data" in accelerated aging testing as the dependent variable (Y), the model Y = aX + b is established. Coefficients a and b are fitted using historical data and used for long-term prediction of new drive test results.

[0258] Generate a visual digital profile: Generate a radar chart containing five dimensions: "Empty Disk Performance", "Half-Disk Performance", "Full Disk Performance", "Performance Under System Stress", and "SLC Cache Stability". The score for each dimension is derived from the normalized value of the corresponding test results.

[0259] Step 6: Automatic diagnosis and report generation after testing

[0260] Automatic secure erasure: After the test, the script automatically calls the nvme format command to securely erase the SSD.

[0261] Report generation: Automatically generates PDF reports containing all test data tables, performance curves, radar chart profiles, performance consistency index (PCI), and recommendation indexes for content creation scenarios (e.g., 4.5 / 5 stars, especially suitable for editing large projects).

[0262] A fifth embodiment is proposed based on the first embodiment. In the fifth embodiment,

[0263] This example uses a 512GB PCIe 3.0 SSD as the test object, focusing on game loading and installation scenarios. The test process is conducted on a single x86 platform, but the test places greater emphasis on response speed. Key differences: Load model: Defined as a "game load model", characterized by:

[0264] rw = randread(predominantly reads random data)

[0265] bs=16k (simulating game resource loading)

[0266] Interspersed short sequential writes to burst (simulating game installation or update).

[0267] Dirty disk test points: Only three points are tested: empty disk, 50% dirty disk (simulating a resident game library), and 90% dirty disk (when space is tight). The test time for each point is shortened to 10 minutes.

[0268] Weighting: Adjusting weights according to the game scenario:

[0269] Random read speed (QD1-QD3) (weight 0.6): directly affects game loading time.

[0270] Write latency (weight 0.2): Affects the game installation and update experience.

[0271] Sequential loading speed (weight 0.2): Affects streaming loading in open-world games.

[0272] System stress test: Simplified, only running the 3DMark stress loop to simulate the system load during game operation.

[0273] Performance profile: The radar chart dimensions have been adjusted to "consistency of loading speed", "consistency of installation speed", and "stability under full space load".

[0274] This embodiment simulates the entire lifecycle of a user's SSD from initial use to full disk usage, sampling performance at multiple key dirty disk points (empty disk, 30%, 40%, 70%, 100%). This ensures the test results are not merely "ideal values" from a laboratory setting, but rather a "practical guide" accurately predicting SSD performance in real-world use, providing unprecedentedly reliable data for consumer purchasing and system integrator selection. It also plots SSD performance degradation curves as the dirty disk percentage changes. By comparing the curves of different SSDs, the garbage collection efficiency of their controller and firmware, the merits of their SLC caching strategies, and performance consistency can be clearly and quantitatively evaluated. By testing at representative dirty disk percentage points (such as the SLC cache exhaustion point for TLC / QLC), this invention effectively stimulates and identifies defects completely hidden in empty disk tests. Cross-testing on both AMD and Intel platforms allows for a systematic evaluation of SSD performance compatibility under different system environments, helping to discover performance issues related to specific platform drivers or configurations. This ensures SSD products provide stable and reliable performance across a wider user base, significantly enhancing market adaptability and competitiveness.

[0275] In the embodiments provided by this invention, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0276] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0277] The above are merely embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for testing the consistency of dirty disk performance of solid-state drives across multiple platforms, characterized in that, The method includes: Obtain the configuration information of the solid-state drive under test and record the SMART data baseline; Based on the original AMD / Intel platform, ARM platform and next-generation platform are added to perform full-disk sequential write and secure erase to ensure that the solid-state drive is in the initialization stage and that the starting point of each test is absolutely consistent. After initialization, the solid-state drive is in an empty state, and steady-state preprocessing is performed and the performance data at this time is recorded as the empty disk benchmark. By sequential or random writing, the dirty disk ratio of the solid-state drive is filled to the target value. Under the dirty disk ratio, a corresponding dynamic load model is applied, and performance sampling and recording are continuously performed to generate a performance degradation curve. While running solid-state drive (SSD) performance benchmark tests, CPU stress tests, memory bandwidth tests, and GPU load tests are launched in the background to assess the SSD's tolerance to system resource contention and to determine the consistency of the SSD's performance data. Machine learning algorithms are used to build a model based on changes in performance degradation curves and SMART data, and the model is used to predict the performance of solid-state drives after long-term use; specifically, this includes normalizing the collected performance data. Weights are assigned to each performance metric based on the sensitivity of different application scenarios; Calculate the overall performance consistency index based on weights; Using machine learning algorithms, based on performance degradation curves, average number of erases and writes in SMART data, and the number of bad blocks as input features, the performance degradation trend of solid-state drives under long-term use is predicted. After the test is completed, the solid-state drive will automatically generate a detailed PDF report containing all test data, curves, charts, consistency indices, and a visual digital profile.

2. The method for testing the consistency of dirty disk performance of solid-state drives across multiple platforms according to claim 1, characterized in that, The steps of obtaining the configuration information of the solid-state drive under test and recording the SMART data baseline include: Obtain the configuration information of the solid-state drive under test, and record key hardware information such as firmware version, controller model, NAND flash memory type, presence and size of DRAM cache, and simulated SLC cache strategy; Perform SMART data baseline recording to fully record SMART data with all readable attributes while the disk is empty.

3. The method for testing the performance consistency of a solid-state drive across multiple platforms with dirty disks according to claim 1, characterized in that, The steps of performing steady-state preprocessing and recording the performance data at this time as an empty disk baseline in the initialization state of the solid-state drive include: In the initial empty disk state, the random read and write performance of the solid-state drive under low queue depth QD1-QD3 was tested. After initialization and in an empty disk state, steady-state preprocessing is performed and the performance data at this time is recorded as the empty disk baseline to ensure that the solid-state drive remains stable during the test.

4. The method for testing the consistency of dirty disk performance of solid-state drives across multiple platforms according to claim 1, characterized in that, The steps of filling the dirty disk ratio of the solid-state drive to a target value through sequential or random writing, applying a corresponding dynamic load model under the dirty disk ratio, and continuously sampling and recording performance data to generate a performance degradation curve include: Create typical application workload models, including office model, content creation model and game model; The load model was accurately simulated using professional disk stress testing tools. By writing sequentially or randomly, the proportion of dirty disks on the solid-state drive is filled to the target value, and a corresponding load model is applied during the writing of each capacity proportion; Continuous performance sampling and recording of performance data are performed at each dirty disk ratio point; Generate a performance degradation curve to observe whether the SSD remains stable or experiences fluctuations and slowdowns under continuous stress.

5. The method for testing the performance consistency of a solid-state drive across multiple platforms with dirty disks according to claim 1, characterized in that, The steps of running solid-state drive (SSD) performance benchmark tests while simultaneously initiating CPU stress tests, memory bandwidth tests, and GPU load tests in the background to assess the SSD's tolerance to system resource contention and determine the consistency of SSD performance data include: While running solid-state drive performance benchmark tests, CPU stress tests, memory bandwidth tests, and GPU load tests are launched in the background. Compare the performance data of solid-state drives under two conditions: system idle and system full load. Assess the SSD's tolerance to system resource contention and determine the consistency of SSD performance data.

6. The method for testing the consistency of dirty disk performance of a solid-state drive across multiple platforms according to claim 5, characterized in that, After the steps of assessing the solid-state drive's tolerance to system resource contention and determining the consistency of the solid-state drive's performance data, the method further includes: Perform SLC cache performance tests, including cache breakdown tests and cache recovery tests.

7. The method for testing the consistency of dirty disk performance of a solid-state drive across multiple platforms according to claim 1, characterized in that, The steps of using machine learning algorithms to build a model based on changes in performance degradation curves and SMART data, and predicting the performance of solid-state drives after long-term use based on the model, include: The normalization process includes at least performance metrics such as sequential read speed, random read speed, and latency. In addition, it integrates performance data, performance metrics, weights, and performance characteristics to generate a visualized digital profile.

8. The method for testing the consistency of dirty disk performance of a solid-state drive across multiple platforms according to claim 1, characterized in that, After the test is completed, the steps for automatically generating a detailed PDF report containing all test data, curves, charts, consistency indices, and a visualized digital profile of the solid-state drive include: Solid-state drive after automatic secure erase test completed; Generate a detailed PDF report containing all test data, curves, charts, consistency indices, and profiles; Based on the needs of different application scenarios, corresponding recommendation indices are provided.

Images