A memory testing system

Abstract

The application discloses a memory test system, and relates to the technical field of computers, which comprises a control device, a first type of network device, second type of network devices, a hardware debugging device and a device to be tested connected with each second type of network device respectively, the control device is connected with each second type of network device through the first type of network device, each second type of network device, the hardware debugging device and the device to be tested corresponding to the second type of network device are in the same local area network, different second type of network devices are in different local area networks, the control device is used for issuing a test task, and a target hardware debugging device is used for adjusting memory test parameters so that a target device to be tested generates a memory test result. Through the application, memory test is simultaneously performed on multiple devices to be tested through the same control device, test efficiency is improved, and the multiple devices to be tested are in different local area networks, so that the test environments of the devices to be tested are independent.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a memory testing system. Background Technology

[0002] Retention margin testing (RMT) is a crucial step in ensuring the long-term stable operation of servers, playing an irreplaceable role in server R&D, verification, quality control, and maintenance. Memory, as a core server component, directly determines the overall reliability of the server through the stability of its electrical parameters (such as voltage, timings, and frequency). RMT testing verifies memory stability under its operating limits, identifying potential hardware defects and parameter drift risks early on, thus preventing serious failures such as device crashes and data corruption caused by memory errors during long-term high-load operation. Therefore, conducting efficient and reliable RMT testing on servers is of great significance for ensuring stable operation throughout the server's entire lifecycle. Summary of the Invention

[0003] This application provides a memory testing system to at least address the problem of how to perform efficient and reliable reserved boundary testing on the test equipment.

[0004] This application provides a memory testing system, which includes: a control device, a first type of network device, at least one second type of network device, and a hardware debugging device and a device under test respectively connected to each second type of network device; the control device is connected to each second type of network device through the first type of network device; each second type of network device and the corresponding hardware debugging device and device under test are all located in the same local area network, and different second type of network devices are located in different local area networks;

[0005] The control device is used to send test tasks to the target hardware debugging device through a first type of network device and a target network device, wherein the target network device is one of at least one second type of network device, and the target hardware debugging device is a hardware debugging device connected to the target network device.

[0006] The target hardware debugging device is used to adjust the memory test parameters of the target device under test in response to the test task, wherein the target device under test is the device under test connected to the target hardware debugging device;

[0007] The target device under test is used to generate memory test results in response to the adjusted memory test parameters;

[0008] The control device is also used to obtain memory test results through the first type of network device and the target network device.

[0009] This application utilizes a single control device to perform memory testing on multiple devices under test, improving testing efficiency. Simultaneously, by placing different devices under test and the hardware debugging devices connected to them on different local area networks (LANs), the testing environments of the devices under test are isolated, avoiding network conflicts (such as inconsistent subnet masks) and data interference risks. Furthermore, when adding a new device under test, only the second type of network device and the hardware debugging device need to be added; there is no need to readjust the existing network consisting of the devices under test and the hardware debugging device, nor is it necessary to equip each device under test with a separate control device, reducing testing costs and increasing the scalability and flexibility of the system. Attached Figure Description

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

[0011] Figure 1 This is a schematic diagram of an architecture for performing boundary preservation testing on a server, provided as an embodiment of this application.

[0012] Figure 2 This is a schematic diagram of the structure of a memory testing system provided in an embodiment of this application;

[0013] Figure 3 This is a schematic diagram illustrating an application scenario for performing boundary-preserving testing on a device under test, as provided in an embodiment of this application. Detailed Implementation

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

[0015] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0016] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0017] First, the application scenarios of the embodiments of this application will be introduced by way of example.

[0018] Figure 1 This is a schematic diagram of an architecture for performing retention margin testing (RMT) on a server. When performing retention margin testing on a server, methods such as... Figure 1 The diagram illustrates a one-to-one architecture of "control unit - hardware debugging device - server". The control unit connects to both the hardware debugging device and the server via a router to initiate test tasks and collect memory test results. However, this approach limits the number of servers a control unit can test to one, resulting in low testing efficiency and poor scalability.

[0019] Figure 2 This is a schematic diagram of the structure of a memory testing system. Figure 2 The system includes: a control device, a first-type network device, at least one second-type network device, and hardware debugging equipment and a device under test connected to each second-type network device; the control device is connected to each second-type network device through the first-type network device. Figure 2 In this configuration, the first type of network device is connected to the second type of network device 1, the second type of network device 2, ..., the second type of network device n through different independent interfaces. The second type of network device 1 is connected to the device under test 1 and the hardware debugging device 1, the second type of network device 2 is connected to the device under test 2 and the hardware debugging device 2, and so on. The second type of network device n is connected to the device under test n and the hardware debugging device n.

[0020] Specifically, the control device, as the core management device of the system, is responsible for initiating test tasks, obtaining memory test results from each device under test, and scheduling multiple test tasks (such as selecting the target device under test from multiple devices under test based on the test task). For example, the device under test can be a server under test (DUT).

[0021] The first type of network is defined as a network device that connects a control device with multiple second type network devices. For example, the first type of network device can be a router, a Layer 3 switch, etc.

[0022] Each type II network device has a corresponding device under test (DUT) and a hardware debugging device, responsible for the network connection between the individual DUT, the individual hardware debugging device, and the control device. For example, type II network devices can be access layer switches, small routers, etc.

[0023] The hardware debugging device is directly connected to the device under test (DUT) and is used to adjust the DUT's memory testing parameters. For example, the hardware debugging device can be a device with a Hardware Debug Tool (HDT) installed.

[0024] In this system, each Type II network device, along with its corresponding hardware debugging and testing devices, resides on the same local area network (LAN), while different Type II network devices are located on different LANs. For example, each Type II network device is configured with an independent network segment, such as 192.168.1.x, 192.168.2.x…192.168.Nx, ensuring no Internet Protocol (IP) address conflicts between Type II network devices. The control device dynamically obtains the IP addresses and status of each network device via Simple Network Management Protocol (SNMP) or Application Programming Interface (API), establishes multi-threaded connection channels, and allocates independent IP address ranges to each Type II network device through the Type I network device.

[0025] In this system, the control device connects to other devices under test (DUTs) via Type I and Type II network devices, enabling centralized management of multiple DUTs. Devices within the same local area network (LAN) can communicate, while devices in different LANs are isolated via Type I network devices. This means different Type II network devices belong to different LANs, preventing interference between test data and network address conflicts. Furthermore, when a Type II network device, a DUT, or a hardware debugging device within a LAN malfunctions, devices in other LANs are not affected by the faulty LAN.

[0026] The control device is used to send test tasks to the target hardware debugging device through the first type of network device and the target network device.

[0027] The target network device is one of at least two types of network devices, and the target hardware debugging device is a hardware debugging device connected to the target network device.

[0028] Specifically, the test task issued by the control device can be a Retention Margin Test (RMT) task, used to verify the stability of the electrical parameters (such as voltage, timing, frequency, etc.) of the memory in the device under test within their boundary ranges, to ensure that the memory chip can operate reliably under various operating conditions. The test task may include memory test parameters that need to be adjusted. For example, the test task could be to test the error conditions of the memory in device 1 within the voltage range of 1.1V to 1.3V.

[0029] For example, the control device issues test tasks via the Secure Shell Protocol (SSH).

[0030] The target hardware debugging equipment is used to adjust the memory test parameters of the target device under test in response to test tasks.

[0031] The target device under test is the device under test that is connected to the target hardware debugging device;

[0032] Specifically, after receiving the test task from the control device, the target hardware debugging device actively and dynamically adjusts the memory core parameters of the device under test to verify the stability of the memory under different parameter conditions, thereby determining the safe operating boundary (margin threshold) of the memory. For example, the test task includes the memory test parameter range and test requirements, such as: voltage adjustment range: 1.10V~1.30V; timing parameter (CL value) adjustment range: 16~20; test requirements: run a 30-minute memory stress test under each parameter combination, recording the number of errors. After receiving the test task, the target hardware debugging device connects to the device under test through a dedicated debugging interface based on the test task and adjusts the memory test parameters accordingly.

[0033] The target device under test is used to generate memory test results in response to the adjusted memory test parameters.

[0034] Specifically, the target device under test includes a memory testing tool (such as the Memeye testing tool). After the target hardware debugging device adjusts the memory testing parameters, the memory testing tool of the device under test is triggered to execute the test and generate memory test results. For example, the memory test results may be: when the voltage is 1.10V + CL16, the memory experiences 3 checksum errors within 5 minutes (unstable); when the voltage is 1.20V + CL18, there are no errors within 30 minutes (stable); when the voltage is 1.30V + CL20, there are no errors within 30 minutes (stable, but with higher power consumption).

[0035] The control device is also used to obtain memory test results through the first type of network device and the target network device.

[0036] For example, both the control device and the target device under test contain memory testing tools. Through communication between the control device and the target device under test (e.g., the memory testing tool in the control device sends Intelligent Platform Management Interface (IPMI) commands to the memory testing tool in the target device under test), the control device obtains the memory test results. The memory test results consist of data and log files generated during the memory test. For example, the memory test results include memory error records, memory block counts, latency, and other performance metrics, as well as quantitative indicators used to evaluate memory stability.

[0037] For example, the data corresponding to each device under test (such as memory test results, test tasks, etc.) is stored in a separate folder in the control device to avoid confusion. In addition, the memory test results of each device under test are stored in the control device with a unique identifier (such as the identifier (ID) of the device under test).

[0038] For example, the control device is also used to perform unified analysis and report generation on the memory test results of each device under test. For instance, by accelerating through a distributed computing framework (such as the big data processing framework (Spark)) or a graphics processing unit (GPU), it can automatically generate margin test threshold curves and fluctuation ranges, and automatically label abnormal data (such as bit flip rate exceeding the threshold).

[0039] For example, when the control device tests multiple devices under test, multi-threading / processing or message queues (such as a distributed stream processing platform (Kafka)) can be used to achieve asynchronous processing and buffering of data streams to avoid blocking.

[0040] This application's embodiments utilize a single control device to perform memory testing on multiple devices under test, improving testing efficiency. Simultaneously, by placing different devices under test and the hardware debugging devices connected to them on different local area networks (LANs), the testing environments of the devices under test are isolated, avoiding network conflicts (such as inconsistent subnet masks) and data interference risks. Furthermore, when adding a new device under test, only the second type of network device and the hardware debugging device need to be added; there is no need to readjust the existing network consisting of the devices under test and the hardware debugging device, nor is it necessary to equip each device under test with a separate control device, reducing testing costs and increasing the system's scalability and flexibility.

[0041] In some embodiments, based on the foregoing embodiments, the target device under test includes a controller and an operating system.

[0042] Specifically, the controller is the hardware management unit in the target device under test, which can be a Baseboard Management Controller (BMC), a Complex Programmable Logic Device (CPLD), etc. The operating system is the software running on the device under test, used to provide the test runtime environment.

[0043] The control device is also used to: remotely control the controller via the first type of network device and the target network device to start the operating system so that the operating system can subsequently respond to the adjusted memory test parameters and generate memory test results.

[0044] In addition to booting the operating system, the controller is also used to perform hardware status detection on the device under test and generate alarm messages when hardware data (such as temperature and power consumption) does not meet preset conditions. For example, a temperature alarm message is generated when the memory temperature in the device under test exceeds a preset temperature threshold.

[0045] In this embodiment, the control device remotely controls the controller in the target device under test through a first type of network device and a target network device. When there are multiple target devices under test, there is no need to manually start the target devices under test, thus improving the convenience of testing.

[0046] In some embodiments, based on the foregoing embodiments, the control device is specifically used for:

[0047] The controller is remotely controlled via a first virtual LAN to start the operating system; and memory test results are obtained via a second virtual LAN.

[0048] Among them, the first virtual LAN and the second virtual LAN are different virtual LANs constructed through the first type of network device and the target network device.

[0049] Specifically, the first virtual LAN is used to transmit control commands, which are used to remotely operate the controller in the device under test. The second virtual LAN is used to transmit memory test results.

[0050] For example, the first interface of the target device under test is connected to the second interface of the target network device via a first physical transmission link, and the third interface of the target device under test is connected to the fourth interface of the target network device via a second physical transmission link. The first physical transmission link is configured as a first virtual local area network (VLAN) through the first VLAN configuration of the first type of network device and the target network device, and the second physical transmission link is configured as a second VLAN through the first type of network device and the target network device. In this way, the first VLAN and the second VLAN are connected to different ports of the target network device, forming a two-layer isolation of physical and logical isolation, ensuring that the network environment of each device under test is completely independent, preventing mutual interference between data and network address conflicts.

[0051] In this embodiment, the network for remote operation of the control controller and the network for transmitting memory test results are isolated from each other, preventing network address conflicts and data interference. Furthermore, when communication problems occur in the system, the fault domain can be quickly located through the division of virtual local area networks (VLANs). For example, if the remote operation command of the control controller cannot be issued, only the link status in the first VLAN needs to be checked; if the memory test result transmission is abnormal, only the link status in the second VLAN needs to be checked, thus shortening the troubleshooting time.

[0052] In some embodiments, based on the foregoing embodiments, the control device is specifically used to: issue test tasks to the target hardware debugging device through a third virtual local area network (VLAN); the third VLAN is a VLAN constructed through a first type of network device and the target network device, and is different from the first VLAN and the second VLAN.

[0053] The third virtual LAN serves as an independent virtual network for issuing test tasks to the target hardware debugging device, isolated from the network transmitting control commands and memory test results. Considering that test tasks typically have high real-time requirements, the third virtual LAN for issuing test tasks is isolated from the first and second virtual LANs to prevent traffic congestion from the first and second virtual LANs, thus ensuring the independence and stability of the test tasks.

[0054] Figure 3 This is a schematic diagram illustrating an application scenario where boundary-preserving testing is performed on the device under test. For example... Figure 3As shown, the control device sends control commands to the target device under test via a first virtual local area network (VLAN) to control the controller in the target device under test and further start the operating system. The control device sends test tasks to the target hardware debugging device via a third VLAN and obtains memory test results from the target device under test via a second VLAN. In this embodiment, network isolation of control commands, test tasks, and memory test results is achieved through a first VLAN (e.g., VLAN ID 1), a second VLAN (e.g., VLAN ID 2), and a third VLAN (e.g., VLAN ID 3), avoiding mutual interference between various types of data during transmission.

[0055] In some embodiments, based on any of the foregoing embodiments, the control device is further configured to:

[0056] After the test on the target device is completed, the power to the target device is turned off via the first virtual LAN control device.

[0057] Reset the virtual local area network constructed by the first-class network device and the target network device;

[0058] Release the interface in the target network device that is connected to the target device under test.

[0059] Specifically, first, the control device sends a shutdown command to the controller of the target device under test via the first virtual LAN to prevent the target device under test from wasting power after the test and to ensure that the target device under test starts from the initial state for the next test. Then, the control device cleans up the dummy LAN configurations on both the first and second type of network devices, such as deleting the VLAN ID, IP address, and other network resources of the virtual LAN built for this test. Finally, the interface of the target network device is restored to its default state, such as restoring the port originally assigned to VLAN 10 to Access mode, so that the interface can be used normally in the next test task, reducing the risk of anomalies.

[0060] In some embodiments, the control device is further configured to: send a pre-configured memory testing tool to the operating system, so that the operating system subsequently generates memory test results through the memory testing tool in response to the adjusted memory test parameters.

[0061] Specifically, after the operating system boots up, the control device triggers the transfer of memory testing tools via a preset transfer protocol. For example, the preset transfer protocol could be SSH, SFTP (Secure File Transfer Protocol), or HTTPS (Hypertext Transfer Protocol Secure). The memory testing tool could be the Memeye testing tool.

[0062] In some embodiments, the control device is also used to detect in real time the link status in the local area network, the traffic and device status (such as hard disk temperature and fan speed) of each device under test. When a link interruption is detected in a local area network, the device connected to that link is automatically isolated and an alarm message is generated.

[0063] In some embodiments, the control device is also used to determine a margin threshold based on memory test results, the specific process of which is as follows:

[0064] First, the control device determines the margin threshold of the target device under test based on the memory test results.

[0065] Specifically, margin thresholds refer to the parameter safety boundaries that ensure the stable operation of the device under test, i.e., the redundancy range reserved based on the baseline parameters. For example, voltage margin thresholds: 1.15V (lower limit) ~ 1.25V (upper limit), timing margin thresholds: column address strobe delay (CL) 17 (lower limit) ~ CL19 (upper limit), frequency margin thresholds: 4600MHz (lower limit) ~ 4800MHz (upper limit).

[0066] Then, the control device obtains the cumulative runtime of the target device under test.

[0067] Specifically, cumulative runtime refers to the total running time of the device under test since it left the factory or was reset.

[0068] Finally, the control device compensates for the margin threshold based on the cumulative running time to obtain the compensated margin threshold.

[0069] Specifically, the compensated margin threshold refers to the final safety boundary parameter adjusted according to the aging of the equipment. Considering that hardware performance naturally ages with increased operating time, this embodiment of the application uses a dynamic adjustment of the margin threshold to offset the effects of natural aging, ensuring that the safety boundary of the device under test remains effective at all times. For example, the original voltage threshold: 1.15V (lower limit) → after compensation: 1.17V (lower limit). Another example: the original timing threshold: CL17 (lower limit) → after compensation: CL18 (lower limit).

[0070] In one possible implementation, the control device determines the margin compensation amount based on the cumulative running time; and obtains the compensated margin threshold based on the margin compensation amount and the margin threshold.

[0071] Optionally, the compensated margin threshold can be determined by a preset mapping relationship between cumulative runtime and margin compensation amount. This mapping relationship can be obtained through aging experiments on a large number of devices. For example, aging tests of different durations (e.g., 0 hours, 1000 hours, 5000 hours, 10000 hours) are performed on reference devices, and memory stability boundary parameters (e.g., lower voltage limit, lower CL value limit) are recorded at each duration. The decay curve between cumulative runtime and margin compensation amount is then fitted, thereby obtaining the mapping relationship between cumulative runtime and margin compensation amount.

[0072] Optionally, the control device obtains the margin compensation amount corresponding to the cumulative running time based on the cumulative running time and the preset compensation model.

[0073] Specifically, the compensation model can be selected based on the equipment type and aging characteristics of the device under test. For example, it can be a linear model, a logarithmic model, a piecewise ladder model, etc. The parameters in the compensation model are obtained by fitting the model based on the aging experiment.

[0074] For example, by using a preset compensation model between cumulative running time and voltage compensation amount, the margin compensation amount corresponding to the voltage is determined, thereby adjusting the margin threshold corresponding to the voltage to obtain the compensated margin threshold corresponding to the voltage. For example, this compensation model is expressed as follows:

[0075]

[0076] in, The voltage margin compensation amount is T, the cumulative running time is T, and a is the first attenuation coefficient, which can be obtained through aging experiments. For example, a is taken as 0.002.

[0077] For example, by using a preset compensation model between cumulative runtime and timing compensation amount, the margin compensation amount corresponding to the timing is determined, thereby adjusting the margin threshold corresponding to the timing to obtain the compensated margin threshold corresponding to the timing. For example, this model is represented as follows:

[0078]

[0079] in, The margin compensation amount is the timing margin, T is the cumulative runtime, and b is the second attenuation coefficient. For example, b is 0.002.

[0080] For example, by using a preset compensation model between cumulative runtime and frequency compensation amount, the frequency margin compensation amount is determined, thereby adjusting the frequency margin threshold to obtain the compensated margin threshold corresponding to the frequency. For example, this model is represented as follows:

[0081]

[0082] in, Where T is the frequency margin compensation amount, T is the cumulative running time, and c is the third attenuation coefficient. For example, c is 0.002.

[0083] Optionally, after determining the margin compensation amount, based on the margin compensation amount, for the lower limit of voltage, the margin threshold and the margin compensation amount are summed to obtain the compensated margin threshold; for the lower limit of timing, the margin threshold and the margin compensation amount are summed to obtain the compensated margin threshold; for the upper limit of frequency, the margin threshold and the margin compensation amount are summed to obtain the compensated margin threshold.

[0084] For example, the original lower voltage limit of 1.15V + compensation of 0.02V → the lower voltage limit after compensation is 1.17V; the original upper frequency limit of 4800MHz + compensation of (-50MHz) → the upper frequency limit after compensation is 4750MHz.

[0085] This is because voltage below the lower limit will cause data errors, timing too strict (CL value too small) will cause read / write synchronization failure, and frequency above the upper limit will cause signal integrity problems. The three parameters of voltage lower limit, timing lower limit, and frequency upper limit directly determine the "safe operating limit" of the device under test. Aging has the most significant impact on it, so it is the focus of compensation.

[0086] In some embodiments, based on any of the foregoing embodiments, the control device is further configured to determine a target device under test, and after determining the target device under test, to issue a test task to the target hardware debugging device corresponding to the target device under test. The specific implementation method for determining the target device under test is as follows:

[0087] a1, the control device acquires the hardware data and network status data corresponding to all devices under test, the historical execution time and historical traffic of the test task, as well as the preset time and preset traffic.

[0088] Specifically, the hardware data of the device under test can include hardware configuration and hardware status information, such as the number of CPU cores, memory capacity, temperature, power status, etc.

[0089] Network status data refers to network connection quality indicators of the device under test, such as bandwidth, latency, packet loss rate, error rate, and network stability.

[0090] Historical execution duration can be the historical execution duration of this test task or the historical execution duration of similar test tasks, and can be used to determine the extent to which the test task consumes the hardware resources of the device under test. For example, the historical execution duration of the memory stress test is 2 hours.

[0091] Historical traffic can refer to the historical traffic of this test task during the test process, or it can refer to the historical traffic of similar test tasks during the test process. It can be used to determine the network resource requirements of the test task. For example, the historical average traffic for transmitting memory test results is 8GB.

[0092] The preset duration and preset traffic can be limited based on experience, and are not limited here. For example, the preset duration can be set to the historical average execution time of similar test tasks, and the preset traffic can be set to the historical average traffic of similar test tasks during the test process.

[0093] a2. The control device determines the target device to be tested based on the hardware data and network status data corresponding to all devices to be tested, as well as the historical execution duration, historical traffic, preset duration, and preset traffic.

[0094] In one possible implementation, the control device determines the target device under test in the following manner:

[0095] First, the control device determines the first weight corresponding to the hardware data and the second weight corresponding to the network status data based on the historical execution duration, historical traffic, preset duration, and preset traffic.

[0096] Optionally, the first weight and the second weight can be determined based on the first difference obtained by subtracting the historical execution duration from the preset duration and the second difference obtained by subtracting the historical traffic from the preset traffic.

[0097] Here, when the first difference is greater than the second difference, the first weight is greater than the second weight. When the first difference is less than the second difference, the first weight is less than the second weight. When the first difference and the second difference are equal, the first weight is equal to the second weight.

[0098] Specifically, when the historical execution duration is longer than the preset duration and the historical traffic is less than or equal to the preset traffic, the first weight is greater than the second weight. That is, for long-running tasks, the first weight corresponding to the hardware data is increased.

[0099] When the historical traffic is greater than the preset traffic and the historical execution time is less than or equal to the preset time, the second weight is greater than the first weight. That is, for high-traffic tasks, the second weight corresponding to the network status data is increased.

[0100] When the historical execution duration is longer than the preset duration and the historical traffic is greater than the preset traffic, or when the historical execution duration is shorter than the preset duration and the historical traffic is less than the preset traffic, the first difference and the second difference are used to determine whether the pressure on the hardware or the pressure on the network are more prominent, and thus determine the first weight and the second weight. When the first difference is greater than the second difference, the first weight is greater than the second weight. When the first difference is less than the second difference, the first weight is less than the second weight. When the first difference and the second difference are equal, the first weight is equal to the second weight.

[0101] This is because long-duration tasks place higher demands on hardware, requiring a higher primary weight for hardware data. Prioritizing devices with high hardware health ensures successful test completion. For high-traffic tasks, network transmission efficiency and reliability are paramount. Insufficient network bandwidth can lead to data transmission timeouts and task failures. Therefore, a higher secondary weight for network status data prioritizes devices with sufficient bandwidth and high stability. When test tasks are both time-consuming and traffic-intensive, it's crucial to determine whether the hardware or network load is more significant. The difference in load determines the primary factor influencing the test. This approach prioritizes long-duration tasks with stable hardware to reduce hardware-related failures, and prioritizes high-traffic tasks with high-quality networks to avoid data transmission timeouts. Matching suitable devices to test tasks improves reliability and balances the load on the devices under test.

[0102] Then, the control device determines the target device to be tested based on the hardware data and network status data corresponding to all devices to be tested, as well as the first weight and the second weight.

[0103] Optionally, the target device to be tested can be determined in the following way:

[0104] First, based on the hardware data and network status data of the first device under test, as well as the first weight and the second weight, the compatibility of the first device under test is determined.

[0105] The first device to be tested is any one of all the devices to be tested.

[0106] Specifically, the compatibility of the device under test reflects the degree to which the device under test is adapted to the test task.

[0107] For example, based on the hardware data corresponding to the first device under test and a preset hardware data scoring rule, a first score for the first device under test on the hardware data is determined. Simultaneously, based on the network status data corresponding to the first device under test and a preset network status data scoring rule, a second score for the first device under test on the network status data is determined. Then, based on a first weight and a second weight, the first score and the second score are weighted and summed to obtain the adaptability of the first device under test.

[0108] The preset hardware data scoring rules can be determined based on factors such as the number of CPU cores, memory capacity, and memory type in the device under test. For example, when the device under test has 32GB of memory, the corresponding first score is 60 points, and when the memory is 64GB, the corresponding first score is 80 points.

[0109] The preset network status data scoring rules can be determined based on factors such as bandwidth, packet loss rate, and latency in the device under test. For example, when the packet loss rate is less than 1%, the corresponding second score is 80, and when the packet loss rate is greater than 1%, the corresponding second score is 60.

[0110] For example, if the first weight is 0.5, the second weight is 0.5, the first score is 100, and the second score is 60, then the fit is... .

[0111] Then, after determining the compatibility of each of the devices to be tested, the target device to be tested is determined based on the compatibility of each of the devices to be tested.

[0112] For example, the device with the highest compatibility among all devices to be tested is selected as the target device to be tested.

[0113] In this embodiment of the application, a suitable device is selected from multiple devices to be tested to meet the actual needs of the test task, ensuring that the device to be tested can meet the needs of the test task and ensuring the reliable execution of the test task.

[0114] Through the above description of the embodiments, those skilled in the art can clearly understand that the system according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0115] Those skilled in the art will further recognize that the units and implementations of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0116] The memory testing system provided in this application has been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to help understand the system and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A memory testing system, characterized in that, The system includes: a control device, a first type of network device, at least one second type of network device, and a hardware debugging device and a device under test respectively connected to each second type of network device; the control device is connected to each second type of network device through the first type of network device; each second type of network device and the corresponding hardware debugging device and device under test are all in the same local area network, and different second type of network devices are in different local area networks; The control device is used to send test tasks to the target hardware debugging device through the first type of network device and the target network device, wherein the target network device is one of the second type of network devices, and the target hardware debugging device is a hardware debugging device connected to the target network device. The target hardware debugging device is used to adjust the memory test parameters of the target device under test in response to the test task, wherein the target device under test is a device under test connected to the target hardware debugging device; The target device under test is used to generate memory test results in response to the adjusted memory test parameters; The control device is also used to obtain the memory test results through the first type of network device and the target network device; The target device under test includes a controller and an operating system; the control device is further used for: The controller is remotely controlled by the first type of network device and the target network device to start the operating system, so that the operating system can subsequently respond to the adjusted memory test parameters and generate the memory test results; The control device is specifically used for: The controller is remotely controlled via a first virtual local area network to start the operating system; In addition, the memory test results are obtained through a second virtual local area network (VLAN), wherein the first VLAN and the second VLAN are different VLANs constructed through the first type of network device and the target network device; The control device is specifically used for: The test task is sent to the target hardware debugging device through a third virtual local area network (VLAN); the third VLAN is a VLAN constructed through the first type of network device and the target network device, and is different from the first VLAN and the second VLAN.

2. The system according to claim 1, characterized in that, The control device is also used for: After the target device under test is tested, the control device is controlled via the first virtual local area network to turn off the power of the target device under test. Reset the virtual local area network constructed by the first type of network device and the target network device; Release the interface in the target network device that is connected to the target device under test.

3. The system according to claim 1, characterized in that, The control device is also used for: The pre-configured memory testing tool is sent to the operating system so that the operating system can subsequently respond to the adjusted memory testing parameters and generate the memory testing results through the memory testing tool.

4. The system according to claim 1, characterized in that, The control device is also used for: Based on the memory test results, determine the margin threshold of the target device under test; Obtain the cumulative runtime of the target device under test; The remaining threshold is compensated based on the cumulative runtime to obtain the compensated remaining threshold.

5. The system according to claim 1, characterized in that, The control device is also used for: Acquire the hardware data and network status data corresponding to all the devices under test, the historical execution time and historical traffic corresponding to the test task, and the preset time and preset traffic; The target device to be tested is determined based on the hardware data and network status data corresponding to all the devices to be tested, as well as the historical execution time, historical traffic, preset time, and preset traffic.

6. The system according to claim 5, characterized in that, The control device is specifically used for: Based on the historical execution duration, the historical traffic, the preset duration, and the preset traffic, a first weight corresponding to the hardware data and a second weight corresponding to the network status data are determined. The target device to be tested is determined based on the hardware data and network status data corresponding to all the devices to be tested, as well as the first weight and the second weight.

7. The system according to claim 6, characterized in that, The step of determining the target device under test based on the hardware data and network status data corresponding to all the devices under test, as well as the first weight and the second weight, includes: Based on the hardware data and network status data corresponding to the first device under test, as well as the first weight and the second weight, the adaptability of the first device under test is determined, wherein the first device under test is any one of all the devices under test; After determining the compatibility of each of the devices under test, the target device under test is determined based on the compatibility of each of the devices under test.

Images