A solid state disk office fluency test method, system and electronic device

Abstract

The application discloses a solid state disk office fluency test method, system and electronic equipment. The method comprises the following steps: simulating office operation sequences for a to-be-tested solid state disk on a control terminal based on a preset office scene script; during the simulation, converting operation instructions of the control terminal into physical trigger signals through a physical synchronizer, triggering data acquisition hardware to collect operation interfaces of the control terminal based on the signals, and acquiring time sequence synchronization interface collection data corresponding to the office operation sequences; and quantifying interface response delays of at least one operation step in the office operation sequences based on the time sequence synchronization interface collection data, and taking the interface response delays as perception delay indexes. The method eliminates software clock jitter through hardware-level physical synchronization, accurately quantifies perception delay and frame freezing proportion, and realizes fluency evaluation that is more consistent with user subjective feeling.

Description

Technical Field

[0001] This application relates to the field of solid-state drive performance testing technology, specifically to a solid-state drive office smoothness testing method, system, electronic device, and computer-readable storage medium. Background Technology

[0002] With the rapid development of cloud computing and big data technologies, the market demand for enterprise-grade solid-state drives (SSDs) continues to rise. SSDs offer advantages such as high read and write speeds and low access latency, meeting the data processing speed requirements of modern enterprises. However, in practical applications, accurately evaluating the smoothness performance of SSDs in office scenarios has become a pressing issue.

[0003] Traditional SSD performance evaluation for office tasks primarily relies on benchmark software such as PCMark 10. Testers run a complete system disk benchmark test, obtain an overall score, and use this score as the sole criterion for measuring SSD performance in office tasks. However, this method has several problems: the overall score masks the detailed performance differences in specific office tasks; it ignores real user experience and cannot quantify the "lag" and "latency" subjectively perceived by users; static testing is detached from reality and cannot reflect the disruption to foreground office smoothness caused by background interference such as WeChat and antivirus software. These shortcomings prevent existing technologies from comprehensively and realistically evaluating the smoothness performance of SSDs in real-world office application scenarios, affecting the accurate optimization and improvement of products. Summary of the Invention

[0004] The main purpose of this application is to provide a method, system, electronic device, and computer-readable storage medium for testing the smoothness of SSD office work, in order to solve the technical problem that existing SSD office performance evaluation methods only focus on machine-level indicators and ignore the subjective feelings of users and the authenticity of actual application scenarios, resulting in test results that cannot accurately reflect the real user experience. This application achieves accurate perception latency measurement and quantification of stuttering ratio based on hardware synchronization, thereby generating a more consistent comprehensive evaluation result of office smoothness that reflects the user's experience.

[0005] To achieve the above objectives, this application adopts the following technical solution: According to the first aspect of this application, a method for testing the smoothness of solid-state drive (SSD) performance in office work is provided, including: Establish a test environment that includes the solid-state drive under test, the control terminal, and the data acquisition hardware; Based on a preset office scenario script, the office operation sequence for the solid-state drive under test is simulated on the control terminal, and the control terminal sends test commands to the physical synchronizer containing programmable relays and optocoupler isolation modules. When simulating the office operation sequence, the test command is converted into a physical electrical signal by a physical synchronizer programmable relay to close the button switch of the test equipment, simulating a physical click operation; at the same time, a TTL pulse signal is sent to the external trigger interface of the data acquisition hardware through the optocoupler isolation module, and the hardware-level synchronous triggering of the data acquisition hardware to collect the operation interface of the control terminal to obtain the interface acquisition data that is time-synchronized with the office operation sequence. Based on the interface data collected in the time-synchronized manner, the interface response delay corresponding to at least one operation step in the office operation sequence is quantified as a perceived delay indicator. Based on system input / output event data collected from the control terminal kernel during the simulation of the office operation sequence, the percentage of time during which lag occurred during the execution of the office operation sequence is quantified as a lag indicator. Based on the perceived latency index and the stuttering index, a comprehensive evaluation result is generated to characterize the office smoothness of the solid-state drive under test.

[0006] According to a second aspect of this application, a solid-state drive (SSD) office performance testing system is provided, comprising: The environment setup module is used to set up a test environment that includes the solid-state drive under test, the control terminal, and the data acquisition hardware. The behavior simulation module is used to simulate an office operation sequence for the solid-state drive under test on the control terminal based on a preset office scenario script, and the control terminal sends test commands to a physical synchronizer containing a programmable relay and an optocoupler isolation module. The physical synchronization control module is used to convert the test command into a physical electrical signal through a physical synchronizer programmable relay to close the button switch of the test equipment and simulate a physical click operation when simulating the office operation sequence. At the same time, the optical isolation module sends a TTL pulse signal to the external trigger interface of the data acquisition hardware, and the hardware-level synchronous triggers the data acquisition hardware to collect data from the operation interface of the control terminal to obtain time-synchronized video acquisition data corresponding to the office operation sequence. The delay quantification module is used to quantify the interface response delay corresponding to at least one operation step in the office operation sequence based on the time-synchronized video acquisition data, as a perceived delay indicator. The stuttering quantification module is used to quantify the percentage of time stuttering that occurs during the execution of the office operation sequence based on system input / output event data collected from the kernel of the control terminal during the simulation of the office operation sequence, and use it as a stuttering indicator. The evaluation generation module is used to generate a comprehensive evaluation result that characterizes the office smoothness of the solid-state drive under test based on the perceived latency index and the stuttering index.

[0007] According to a third aspect of this application, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the program to implement the solid-state drive office smoothness testing method as described above.

[0008] According to a fourth aspect of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the solid-state drive office smoothness testing method as described above.

[0009] In the solid-state drive office smoothness testing method, system, electronic device, and computer-readable storage medium provided in this application, the operation commands of the control terminal are first synchronously converted into physical trigger signals by a physical synchronizer. Based on these physical trigger signals, data acquisition hardware is synchronously triggered to collect data, thereby achieving hardware-level synchronization between the issuance of operation commands and data acquisition. This eliminates measurement errors caused by operating system scheduling and software clock jitter, providing a high-precision time benchmark for accurately quantifying the perceived latency from user operation to interface response. Based on this precise timing synchronization data, this application can quantify the interface response latency (i.e., perceived latency) of specific office operation steps, overcoming the defect of traditional test scores masking detailed performance differences. It can accurately reflect the response speed of specific office actions such as saving PPTs and loading web pages. Simultaneously, this application quantifies the proportion of time spent in lag during the execution of office operation sequences (i.e., lag index) by collecting system input / output event data from the control terminal kernel. This is more sensitive than traditional average latency indicators in capturing the "micro-lag" phenomenon masked by average performance. Finally, the comprehensive evaluation results generated by combining perceived latency and stuttering metrics comprehensively evaluated the SSD's office smoothness from two dimensions: "response speed" and "stuttering frequency," significantly improving the consistency between test results and users' actual subjective experience. Attached Figure Description

[0010] The accompanying drawings are provided to further understand this application, making other features, objectives, and advantages of this application more apparent. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a flowchart illustrating a method for testing the smoothness of office work using a solid-state drive, as provided in an embodiment of this application.

[0011] Figure 2 This is a schematic diagram of a solid-state drive office smoothness testing system provided in an embodiment of this application. Detailed Implementation

[0012] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0013] This application addresses the problem of inaccurate and incomplete assessments of SSD office smoothness in existing technologies by proposing an innovative testing method. This method focuses on accurately quantifying the "lag" and "stuttering" subjectively perceived by users in real or simulated office environments, providing more user-friendly data support for SSD performance evaluation and optimization.

[0014] Before describing the embodiments in detail, some key terms involved in this application will be explained first: Solid-state drive (SSD) office smoothness: refers to the overall smoothness experienced by users when the SSD supports daily office software operation, from issuing operation commands to obtaining visual or functional responses from the interface. Its core evaluation dimensions include response speed and frequency of stuttering.

[0015] Perceived latency metric: This refers to the time elapsed from the "physical start point" of a user's action to the "fully rendered and stable" interface. This metric aims to quantify the system response latency that is perceptible to the user.

[0016] Lag Metric: In this application, it specifically refers to "lag percentage," which is the ratio of the total time during which the system experiences perceptible pauses due to excessive input / output latency caused by the solid-state drive during the execution of the entire office operation sequence to the total duration of the entire operation sequence. It is used to measure the frequency of lag occurrences.

[0017] Physical synchronizer: A hardware device that converts electrical signal operation commands from a control terminal into at least one physical trigger signal with extremely high time accuracy, used to simultaneously drive physical input devices and trigger data acquisition hardware to eliminate measurement errors introduced by software scheduling and system clock jitter.

[0018] The Sigmoid function, a commonly used sigmoid function in machine learning, is borrowed in this application as a normalization mapping function. Its characteristic is that it smoothly maps a real value with a potentially large range to a fixed fractional interval. The function curve changes significantly near the threshold, which is consistent with the non-linear perception of human eyes regarding delay from "insensible" to "unacceptable".

[0019] Region of Interest (ROI): One or more specific rectangular regions pre-defined in an image or video frame. During analysis, only the pixel changes in these regions are considered to represent the rendering state of key elements in the entire complex interface, thereby simplifying the analysis complexity and improving the efficiency and accuracy of judgment.

[0020] Figure 1 A flowchart illustrating a method for testing the smoothness of solid-state drives (SSDs) in office applications is shown. Figure 1 As shown in the figure, this application embodiment provides a method for testing the smoothness of solid-state drives in office work, the method including: S101, setting up a test environment that includes the solid-state drive under test, control terminal and data acquisition hardware; S102, based on a preset office scenario script, simulate an office operation sequence for the solid-state drive under test on the control terminal, and send test instructions from the control terminal to a physical synchronizer containing a programmable relay and an optocoupler isolation module. S103, when simulating the office operation sequence, the test command is converted into a physical electrical signal by a physical synchronizer programmable relay to close the button switch of the test equipment to simulate a physical click operation; at the same time, a TTL pulse signal is sent to the external trigger interface of the data acquisition hardware through the optocoupler isolation module, and the hardware-level synchronous triggering of the data acquisition hardware to collect the operation interface of the control terminal to obtain the interface acquisition data that is time-synchronized with the office operation sequence. S104, Based on the interface acquisition data of the time synchronization, quantify the interface response delay corresponding to at least one operation step in the office operation sequence as a perceived delay indicator. S105, based on the system input / output event data collected from the control terminal kernel during the simulation of the office operation sequence, quantify the proportion of time that lags during the execution of the office operation sequence as a lag indicator; S106, Based on the perceived latency index and the stuttering index, generate a comprehensive evaluation result to characterize the office smoothness of the solid-state drive under test.

[0021] In this embodiment, the aforementioned steps work together to construct a closed-loop, objective testing process from "operation triggering" to "result generation." Steps S101 and S102 establish a testing foundation that closely resembles a real office scenario. Step S103 is the core of the entire method, enabling high-precision measurement. It establishes a hardware-level time synchronization benchmark between operation commands, physical actions, and data acquisition through a physical synchronizer, fundamentally eliminating the interference of operating system scheduling uncertainty on time measurement. Based on this precise time benchmark, step S104 can reliably separate the actual response latency of each operation step from the interface-collected data, while step S105 can accurately calculate the actual "lag time" blocked by slow I / O. Finally, step S106 merges these two objective indicators reflecting user experience from different dimensions, generating a comprehensive evaluation result that more fully and realistically characterizes the smoothness of SSD office work, solving the technical problem that traditional testing methods mask details and deviate from real-world experience with total scores.

[0022] Taking a specific application scenario as an example, testers need to evaluate the smoothness of a newly developed solid-state drive (SSD) when running large Excel files. First, step S101 is executed, installing the SSD under test into the computer serving as the control terminal and connecting a high-speed camera and a physical synchronizer. Next, step S102 is executed, starting a preset "Excel complex table processing" script. This script simulates a user double-clicking to open a workbook containing numerous formulas and charts. When the script executes the instruction to "click the save button," step S103 is initiated: the control terminal sends an electrical pulse to the physical synchronizer; within the same microsecond of receiving the pulse, the physical synchronizer simultaneously drives a relay to simulate a physical mouse clicking the save button on the screen and sends a trigger signal to the high-speed camera, which then begins recording the screen. Based on the video data obtained in step S103, which is strictly synchronized with the time sequence, step S104 analyzes the time difference between the "simulated click" frame and the frame where "the save progress bar completely disappears and the file interface returns to static," accurately calculating the perceived latency of the "save operation" to be 150 milliseconds. Meanwhile, throughout the test, step S105 monitored kernel I / O events and calculated the total time accumulated for all I / O operations with a single latency exceeding 50 milliseconds to be 1.2 seconds, while the entire script execution time was 60 seconds, thus calculating the stuttering percentage SR = 0.02. Finally, step S106 converted the perceived latency of 150 milliseconds and the stuttering percentage of 0.02 into an intuitive office smoothness index through weighted calculation, such as OFI = 85 points, thereby providing a quantitative, comprehensive, and user-realistic evaluation of the SSD's office smoothness performance.

[0023] In one embodiment, regarding step S102 mentioned above, this step simulates an office operation sequence based on a preset office scenario script. Specifically, it includes executing the simulation based on both a cold start mode script and a warm start mode script to obtain perceived latency and stuttering metrics under different system states. In other words, the behavioral simulation process is not limited to a single state but covers typical scenarios with different computer loads and cache states. The cold start mode simulates the situation when the computer is first turned on and the system cache is empty, reflecting the SSD's responsiveness under the "worst-case" condition. The warm start mode simulates a scenario where, after the computer has been running for a long time, system memory is heavily occupied by application cache, and the SSD may face more cache write-back and random read / write contention, which better exposes its stability defects under sustained load. By executing these two modes of testing separately, performance data of the SSD under two extreme but common states can be obtained, making the final comprehensive evaluation result more comprehensive and representative, overcoming the limitations of traditional single-state testing. Furthermore, combined with the above principles, this method can more comprehensively evaluate the real performance of the SSD in actual, variable working environments.

[0024] In one embodiment, regarding step S103 mentioned above, this step uses a physical synchronizer to synchronously convert the operation instructions of the control terminal into physical trigger signals. Specifically, the physical synchronizer receives the operation instructions in the form of electrical signals issued by the control terminal and converts the operation instructions into relay control signals for simulating physical click actions and hardware trigger pulses for triggering the data acquisition hardware to start acquisition. The physical synchronizer receives electrical signals from the control terminal's software layer or I / O port, such as a TTL high level, and splits them in two at the hardware logic level: one path is converted into a signal to drive the relay coil to open and close, thereby indirectly controlling the microswitch action of a real physical mouse, simulating a physical click indistinguishable from human operation; the other path generates a standard hardware trigger pulse, such as a rising edge, through signal conditioning and is directly sent to the trigger port of the data acquisition hardware. This method ensures that the three events of "software instruction issuance," "physical action occurrence," and "data acquisition start" are strictly synchronized on a microsecond-level time scale, eliminating random jitter introduced by software call delays, operating system interrupt handling, etc., and laying an absolutely reliable time reference for subsequent latency quantization. Furthermore, based on the above principles, this method can fundamentally ensure the accuracy of the starting point for perceptual delay measurement.

[0025] In one embodiment, the implementation of step S103 of the aforementioned physical synchronizer is further defined as follows: the physical synchronizer includes a programmable relay module and an optocoupler isolation module. The input terminal of the relay module is connected to the general input / output interface of the control terminal, and the output terminal is connected to the microswitch of the physical mouse. The input terminal of the optocoupler isolation module is connected to the trigger signal output terminal of the control terminal, and the output terminal is connected to the trigger input port of the data acquisition hardware. The relay module is responsible for executing high-precision physical switching actions, converting electrical commands into mechanical actions. The optocoupler isolation module utilizes the principle of optocoupler coupling to achieve electrical isolation between the control terminal circuit and the data acquisition hardware circuit, preventing mutual interference from ground loop noise or voltage surges, and ensuring the purity and stability of the trigger signal. The two modules work together to construct a reliable and interference-resistant hardware synchronization bridge. As a specific implementation, the relay module can use an ultra-small power relay with a switching time of less than 1 millisecond; the optocoupler isolation module can use a high-speed optocoupler with a transmission delay in the nanosecond range. Programmability allows the control terminal to adjust parameters such as pulse width and trigger timing to adapt to different test scenarios.

[0026] The physical synchronizer uses a microcontroller unit as its central processing chip. The electrical connections and control topology of the physical synchronizer are as follows: 1. The microcontroller's Universal Asynchronous Receiver / Transmitter (UART) interface establishes a communication connection with the control terminal's USB interface via a USB-to-TTL serial port chip to receive standard serial test commands from the control terminal. 2. The microcontroller's first General Purpose Input / Output (GPIO) pin is connected to the control terminal of the programmable relay module via a current-limiting resistor; the output contacts of the programmable relay module are directly soldered in parallel to the pins of the left-hand microswitch of the test equipment via wires. 3. The microcontroller's second General Purpose Input / Output (GPIO) pin is directly connected to the positive input terminal of the optocoupler isolation module; the positive and negative output terminals of the optocoupler isolation module are connected to the Signal and GND terminals of the external pin trigger interface of the industrial camera via shielded wires, respectively.

[0027] When the control terminal issues a test command, the microcontroller unit pulls the first and second GPIO pins high simultaneously within the same internal clock cycle via register operations: the first GPIO pin outputs a high level to turn on the solid-state relay, thereby short-circuiting the two ends of the mouse microswitch and physically triggering the test device to perform a click operation; at the same time, the second GPIO pin outputs a high level to activate the optocoupler isolation module, outputting a rising-edge TTL hard trigger pulse signal with a pulse width of 2 milliseconds and a voltage of 5V to the external trigger interface of the industrial camera, causing the industrial camera to instantly start hardware-level frame-by-frame recording. Because it bypasses the operating system's software protocol stack and clock scheduling, the hardware synchronization error between the two physical trigger signals is less than 5 microseconds, fundamentally eliminating the interference of software clock jitter on the starting point of the delay test.

[0028] In one embodiment, regarding step S104 mentioned above, this step quantifies the interface response latency based on the time-synchronized interface acquisition data, specifically including: extracting the video frame sequence corresponding to the operation step from the time-synchronized interface acquisition data; performing image difference analysis on the preset Region of Interest (ROI) in the video frame sequence, and determining the moment when the interface rendering is completed based on the analysis results. This method transforms the abstract "interface response completion" into a calculable image state change problem. First, based on the precise timestamp established in step S103, continuous video frames starting before and after the operation command is issued can be accurately extracted. Then, instead of analyzing the complex and ever-changing content of the entire screen, the focus is on predefined key areas that represent the completion of the operation, such as the "Save" button area of ​​the "Save As" dialog box. By analyzing the pixel changes of this region of interest in a series of continuous frames, the turning point from "changing" to "stable and still" of the interface can be objectively determined, and the moment corresponding to this turning point is determined as the rendering completion moment. By calculating the difference between this completion moment and the operation trigger moment, the precise perceived latency is obtained. This quantitative method overcomes the subjectivity and inaccuracy of human judgment.

[0029] In one embodiment, the image difference analysis and determination method mentioned above is specifically implemented as follows: the image difference analysis is a pixel difference method, and the determination is as follows: when the rate of change of pixel grayscale values ​​ΔP in the region of interest for N consecutive frames is continuously less than a preset threshold δ, the first frame time is recorded as the rendering completion time. The pixel difference method calculates the average or sum of the grayscale value differences of all corresponding pixels in the region of interest between two consecutive frames to obtain a scalar ΔP, which is used to characterize the inter-frame change amplitude. A very small threshold δ is set, for example, ΔP < 0.5%. When ΔP in N consecutive frames is less than δ, the interface is considered to have stabilized, and rendering stops. The timestamp corresponding to the first frame at the beginning of this stable state is determined as the rendering completion time. This determination logic based on the stability of consecutive multi-frames can effectively filter out single-frame misjudgments caused by slight screen jitter, camera noise, etc., improving the robustness and accuracy of the rendering completion time determination. Furthermore, combined with the above principles, this method can achieve automated and high-precision detection of interface state changes.

[0030] In one embodiment, regarding step S105 mentioned above, this step quantifies the percentage of time that lags during the execution of the office operation sequence. Specifically, it is simplified as follows: The cumulative time when the system input / output event delay exceeds a preset threshold is counted, and the ratio of the cumulative time to the total execution time of the office operation sequence is calculated as the lag percentage. Here, "system input / output events" specifically refers to I / O operations related to the solid-state drive under test, which can be obtained through kernel tracing tools or driver layer filtering. A "lag" I / O latency threshold is defined. Whenever the completion time of an I / O operation exceeds the sum of its submission time and this threshold, the system is considered to be in a lag state during this I / O operation. The duration of all such excessive I / O operations (i.e., "cumulative time") is accumulated, and then divided by the total execution time of the entire test script to obtain a proportion value, i.e., the lag percentage. This indicator directly reflects what percentage of the total test time the user experiences "unsmoothness," and more accurately describes the perceived impact of lag than simply counting the number of excessive events.

[0031] In one embodiment, the aforementioned preset threshold is specifically defined as 50 milliseconds. This is an empirical value determined based on extensive user experience research. If an I / O operation has a latency exceeding 50 milliseconds, it is generally perceived by most users as a "minor stutter." Therefore, using this threshold as the boundary for measuring stuttering makes the quantitative results more consistent with human perception models. Using 50 milliseconds as a unified standard also makes the stuttering percentage results comparable between different tests and between different solid-state drives.

[0032] In one embodiment, regarding step S106 mentioned above, this step generates a comprehensive evaluation result characterizing the office smoothness of the solid-state drive under test. Specifically, it is implemented by generating an Office Smoothness Index (OFI) based on the perceived latency index and the stuttering index. Integrating multi-dimensional raw indicators into a single, intuitive Office Smoothness Index (OFI) greatly facilitates the interpretation of test results and the horizontal comparison between different solid-state drives. As a comprehensive score, the OFI carries dual information on response speed and smoothness stability. As a specific implementation, the calculation of this OFI can be combined with the Sigmoid mapping and weighting method in subsequent embodiments.

[0033] In one embodiment, the steps for generating the Office Fluency Index (OFI) mentioned above are further refined as follows: the perceived latency index and the lag index are mapped to individual scores using a preset Sigmoid function; the individual scores are then weighted and summed according to preset weights to obtain the Office Fluency Index (OFI). Specifically, the perceived latency index (PL, in milliseconds) and the lag percentage index (SR, dimensionless) are first mapped to a 0-100 score range using their respective Sigmoid functions. For example, for perceived latency PL, its score S_pl = 100 / (1 + e^{k(PL-m)}), where k and m are shape and midpoint parameters. For lag percentage SR, its score S_sr = 100 / (1 + e^{k(SR-n)}). Next, pre-defined weights are assigned to the two individual scores (for example, perceived latency weight W_pl=0.45, stuttering percentage weight W_sr=0.40; additional weights are applied if other metrics such as cold start time are considered), resulting in OFI = W_pl. S_pl + W_sr S_sr +…。 This approach has two major advantages: First, it achieves non-linear normalization through the Sigmoid function, which amplifies small changes in the index near the threshold, aligning with the human eye's sensitivity to "critical points"; Second, by presetting weights, the contribution of different performance dimensions to the final fluency evaluation can be flexibly adjusted, making OFI more suitable for the needs of specific evaluation scenarios.

[0034] In one embodiment, step S102, which simulates an office operation sequence for the solid-state drive under test, further includes: running a preset interference task in parallel in the background of the control terminal, wherein the interference task continuously occupies system computing and input / output resources. This operation aims to simulate a real office environment where other applications (such as instant messaging software, security software, and streaming media players) constantly compete for system resources in the background while the foreground office software is running. By introducing this controllable and continuous resource occupation, the solid-state drive can be tested under more stringent and realistic load pressure, thereby exposing its potential performance shortcomings in multi-task concurrent scenarios, such as increased lag in foreground office work or a surge in response latency. This makes the test results no longer "laboratory data" under ideal conditions, but "real-world scenario data" with greater reference value.

[0035] In one embodiment, the aforementioned interference task is specifically defined as: a task of software decoding a high-definition video stream at a fixed bitrate. Choosing video decoding as the interference task is typical because it continuously consumes both CPU computing resources and disk I / O resources, and the load is relatively stable and controllable. By specifying a fixed video bitrate, the interference intensity and pattern can be ensured to remain consistent in each test, avoiding additional variables introduced by performance fluctuations of the interference task itself, thereby guaranteeing the repeatability and fairness of the test. Using software decoding instead of hardware decoding is to maximize CPU resource utilization and generate more significant system load pressure.

[0036] In one embodiment, the criteria for judging the perceived latency mentioned above are as follows: a perceived latency greater than 100 milliseconds is considered sluggish, and a latency greater than 300 milliseconds is considered unacceptable. These two thresholds are set based on general understanding in the field of human-computer interaction and user experience research, and can be 100ms and 300ms respectively. A perceived latency of less than 100 milliseconds is usually imperceptible to users, giving a smooth experience; between 100 and 300 milliseconds, users begin to feel a noticeable separation between the operation and the feedback, i.e., a "sluggish feeling"; and exceeding 300 milliseconds, this waiting usually makes users impatient and is judged as "unacceptable." In the test report, in addition to giving specific latency values, qualitative evaluations such as "excellent," "good," and "poor" can also be given based on this standard, making the results easier to understand and communicate.

[0037] In one embodiment, the specific content of the aforementioned preset office scenario script includes at least one of the following: Excel spreadsheet processing, PowerPoint presentation browsing, and webpage loading. These are the most typical and varied scenarios in current computer-based office work. Excel spreadsheet processing tests the SSD's sequential write, random write, and response capabilities to sudden large I / O operations. PowerPoint presentation browsing tests the SSD's response speed to random reads of small files. Webpage loading involves reading and caching a large number of scattered small files. By combining these scenario scripts, the office performance of the solid-state drive under different I / O modes can be comprehensively evaluated. The script can record real user operation trajectories and add 2-5 seconds of random thinking time to simulate a more realistic human operation rhythm.

[0038] It should be noted that, in some optional implementations, the data acquisition hardware can be a high-speed industrial camera supporting an acquisition rate of no less than 240 frames per second (fps) to ensure sufficient temporal resolution for accurate measurement of millisecond-level latency. The control terminal can be equipped with a Windows or Linux operating system and use scripts developed in languages ​​such as Python and C# to control the simulation of office scenarios and the scheduling of testing processes. Acquiring system input / output event data from the kernel can be achieved on the Windows platform using ETW (Event Tracing for Windows) with the correct DiskIo, FileIo, and process ID filters configured; on the Linux platform, it can be achieved using the block device event tracing function of tools like ftrace or perf. The parameters k (slope factor) and m (midpoint value) in the preset Sigmoid function mapping can be adjusted according to the actual data distribution and evaluation criteria. For example, for the perceived latency index, m=150 and k=0.03 can be set so that a latency of approximately 150ms is mapped to approximately 50 minutes. The specific location and size of the Region of Interest (ROI) can be predefined by the testing software through a configuration file. For example, for a save operation, the ROI can be set in the overlapping area of ​​the save progress bar and the file window title bar. In Embodiment 2 (the apparatus described below), the functions of each module (environment setup module, behavior simulation module, etc.) can be implemented by dividing different functional units and calling different APIs or libraries in a unified testing software platform. Libraries such as OpenCV are used for video analysis, and custom drivers are used to communicate with the physical synchronizer. They share test data and status and work together to complete the entire test process.

[0039] In other alternative embodiments, further refinement of the claims is possible. For example, the implementation of the "physical synchronizer" is not limited to a combination of relays and optocouplers; any hardware circuit capable of achieving high-precision synchronous conversion between electrical signals and physical signals falls within the scope of this application. The "image difference analysis" can also be other methods besides pixel difference analysis, such as Structural Similarity Index (SSIM) analysis, feature point matching, etc., as long as it can determine the moment when the interface tends to stabilize based on the image sequence. The calculation of the "cumulative time" can be a simple summation of the duration of a single excessive I / O operation, or a more accurate union time calculation considering overlapping I / O operations.

[0040] This application also provides a solid-state drive (SSD) office smoothness testing system. Figure 2 A schematic diagram of the system's modules is shown. (For example...) Figure 2 As shown, the system includes: Environment setup module 201 is used to set up a test environment that includes the solid-state drive under test, control terminal and data acquisition hardware; The behavior simulation module 202 is used to simulate an office operation sequence for the solid-state drive under test on the control terminal based on a preset office scenario script, and the control terminal sends test commands to a physical synchronizer containing a programmable relay and an optocoupler isolation module. The physical synchronization control module 203 is used to convert the test command into a physical electrical signal through a physical synchronizer programmable relay to close the button switch of the test equipment and simulate a physical click operation when simulating the office operation sequence. At the same time, it sends a TTL pulse signal to the external trigger interface of the data acquisition hardware through the optocoupler isolation module, and the hardware-level synchronous triggers the data acquisition hardware to collect data from the operation interface of the control terminal to obtain time-synchronized video acquisition data corresponding to the office operation sequence. The delay quantization module 204 is used to quantify the interface response delay corresponding to at least one operation step in the office operation sequence based on the time-synchronized video acquisition data, as a perceived delay indicator. The stuttering quantification module 205 is used to quantify the proportion of stuttering time during the execution of the office operation sequence based on system input / output event data collected from the kernel of the control terminal during the simulation of the office operation sequence, and use it as a stuttering indicator. The evaluation generation module 206 is used to generate a comprehensive evaluation result that characterizes the office smoothness of the solid-state drive under test based on the perceived latency index and the stuttering index.

[0041] Through the collaboration of various modules, the system combines hardware and software to achieve all the steps and beneficial effects of the aforementioned method embodiments, and can automatically and accurately complete the testing and evaluation of the smoothness of solid-state drive office work.

[0042] This application also provides an electronic device. The electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the solid-state drive office smoothness testing method described above. This electronic device can serve as a control terminal, or as a dedicated testing device integrating a control terminal and testing and analysis functions.

[0043] This application also provides a computer-readable storage medium. A computer program is stored thereon, which, when executed by a processor, implements the solid-state drive office smoothness testing method described above. The storage medium can be ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical storage device, etc., and the program stored therein enables general-purpose or special-purpose data processing devices to execute the testing method described in this application.

[0044] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for testing the smoothness of solid-state drive (SSD) performance in office work, characterized in that, include: Set up a test environment that includes the solid-state drive under test, the control terminal, and the data acquisition hardware; Based on a preset office scenario script, the office operation sequence for the solid-state drive under test is simulated on the control terminal, and the control terminal sends test commands to the physical synchronizer containing programmable relays and optocoupler isolation modules. When simulating the office operation sequence, the test command is converted into a physical electrical signal by a physical synchronizer programmable relay to close the button switch of the test equipment, simulating a physical click operation; at the same time, a TTL pulse signal is sent to the external trigger interface of the data acquisition hardware through the optocoupler isolation module, and the hardware-level synchronous triggering of the data acquisition hardware to collect the operation interface of the control terminal to obtain the interface acquisition data that is time-synchronized with the office operation sequence. Based on the interface data collected in the time-synchronized manner, the interface response delay corresponding to at least one operation step in the office operation sequence is quantified as a perceived delay indicator. Based on system input / output event data collected from the control terminal kernel during the simulation of the office operation sequence, the percentage of time during which lag occurred during the execution of the office operation sequence is quantified as a lag indicator. Based on the perceived latency index and the stuttering index, a comprehensive evaluation result is generated to characterize the office smoothness of the solid-state drive under test.

2. The method for testing the smoothness of solid-state drive office operations according to claim 1, characterized in that, The simulated office operation sequence based on the preset office scenario script includes: The simulation was executed based on both the cold start mode script and the warm start mode script to obtain the perceived latency and stuttering indicators under different system states.

3. The method for testing the smoothness of solid-state drive office operations according to claim 2, characterized in that, The step of synchronizing the operation commands of the control terminal into physical trigger signals via a physical synchronizer includes: The physical synchronizer receives operation commands in the form of electrical signals from the control terminal, and converts the operation commands into relay control signals for simulating physical click actions and hardware trigger pulses for triggering the data acquisition hardware to start acquisition.

4. The method for testing the smoothness of solid-state drive office operations according to claim 3, characterized in that, The physical synchronizer includes a programmable relay module and an optocoupler isolation module; The input terminal of the relay module is connected to the general input / output interface of the control terminal, and the output terminal is connected to the micro switch of the physical mouse. The input terminal of the optocoupler isolation module is connected to the trigger signal output terminal of the control terminal, and the output terminal is connected to the trigger input port of the data acquisition hardware.

5. The method for testing the smoothness of solid-state drive office operations according to claim 2, characterized in that, The comprehensive evaluation result generated to characterize the office smoothness of the solid-state drive under test is specifically as follows: Based on the perceived latency index and the lag index, the Office Fluency Index (OFI) is generated.

6. The method for testing the smoothness of solid-state drive office operations according to claim 5, characterized in that, The generation of the Office Fluency Index (OFI) includes: The perceived latency index and the stuttering index are respectively mapped to individual scores using a preset Sigmoid function; The scores of each item are weighted and summed according to preset weights to obtain the Office Fluency Index (OFI).

7. The method for testing the smoothness of solid-state drive office operations according to claim 2, characterized in that, The simulated office operation sequence for the solid-state drive under test further includes: A preset interference task runs in parallel in the background of the control terminal, and the interference task continuously occupies the system's computing and input / output resources.

8. A solid-state drive (SSD) office smoothness testing system, characterized in that, include: The environment setup module is used to set up a test environment that includes the solid-state drive under test, the control terminal, and the data acquisition hardware. The behavior simulation module is used to simulate an office operation sequence for the solid-state drive under test on the control terminal based on a preset office scenario script, and the control terminal sends test commands to a physical synchronizer containing a programmable relay and an optocoupler isolation module. The physical synchronization control module is used to convert the test command into a physical electrical signal through a physical synchronizer programmable relay to close the button switch of the test equipment and simulate a physical click operation when simulating the office operation sequence. At the same time, the optical isolation module sends a TTL pulse signal to the external trigger interface of the data acquisition hardware, and the hardware-level synchronous triggers the data acquisition hardware to collect data from the operation interface of the control terminal to obtain time-synchronized video acquisition data corresponding to the office operation sequence. The delay quantification module is used to quantify the interface response delay corresponding to at least one operation step in the office operation sequence based on the time-synchronized video acquisition data, as a perceived delay indicator. The stuttering quantification module is used to quantify the percentage of time stuttering that occurs during the execution of the office operation sequence based on system input / output event data collected from the kernel of the control terminal during the simulation of the office operation sequence, and use it as a stuttering indicator. The evaluation generation module is used to generate a comprehensive evaluation result that characterizes the office smoothness of the solid-state drive under test based on the perceived latency index and the stuttering index.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the program, it implements the solid-state drive office smoothness test method as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the solid-state drive office smoothness test method as described in any one of claims 1 to 7.

Images