Congestion control capability test method and electronic equipment

Abstract

The invention provides a congestion control capability test method and electronic equipment. The method comprises the following steps: controlling an ith device in N devices in a network to be tested to send first flow data to a jth device so as to obtain an ijth transmission parameter; controlling the jth device to send the first flow data to the ith device to obtain the jith transmission parameter so as to obtain N (N-1) transmission parameters; according to the N (N-1) transmission parameters, determining whether the N devices and the switch have faults or not; in M fault-free devices, controlling M-2 devices to send second flow data to the kth device, and one device to send the second flow data and third flow data to the kth device so as to obtain the kth small flow time delay corresponding to the third flow data; and according to the N (N-1) transmission parameters and the M small flow time delays corresponding to the third flow data, judging whether the congestion control capability of the to-be-tested network is qualified or not. According to the embodiment of the invention, the congestion control capability can be tested without accessing the switch.

Description

Background Art

[0002] At present, programmable network congestion control technology is becoming more and more mature, and the congestion control algorithm of the RDMA network in the network cluster, such as the intelligent computing center and the storage center, is updated and iterated rapidly. After each algorithm iteration, the congestion control capability of the congestion control algorithm needs to be evaluated to ensure that the capability of the congestion control algorithm can meet the business requirements. The performance evaluation of the congestion control algorithm is a key link in the algorithm performance verification.

[0003] In related technologies, it is necessary to determine the congestion control capability of the algorithm by accessing the switch queue. However, since switches in existing networks are usually maintained by dedicated personnel, it is usually difficult for end-side network card operation and maintenance personnel to access them, making them difficult to deploy.

[0004] Therefore, a method is needed to accurately and efficiently evaluate the congestion control capability of a congestion control algorithm without accessing the switch.

[0005] It should be noted that the information disclosed in the above background technology section is only used to enhance the understanding of the background of the present disclosure, and therefore may include information that does not constitute the prior art known to ordinary technicians in the field. Summary of the invention

[0006] The purpose of the present disclosure is to provide a congestion control capability testing method and electronic device, which are used to automatically and accurately evaluate the congestion control capability of a network to be tested without accessing a switch.

[0007] According to a first aspect of an embodiment of the present disclosure, a congestion control capability testing method is provided, comprising: determining N devices in a network to be tested, wherein the N devices are connected to at least one switch; controlling the i-th device to send first flow data to the j-th device to obtain the ij-th transmission parameter; controlling the j-th device to send the first flow data to the i-th device to obtain the ji-th transmission parameter, thereby obtaining N(N-1) transmission parameters, 1≤i≤N, 1≤j≤N, i≠j; determining whether the N devices and the switches connected to the N devices are faulty according to the N(N-1) transmission parameters, and replacing the faulty switches and The devices are respectively marked as a faulty switch and a faulty device, and the device connected to the faulty switch is marked as a faulty device; among the M devices of the N devices except the faulty device, M-2 devices are controlled to send the second flow data to the kth device, and one device sends the second flow data and the third flow data to the kth device to obtain the kth small flow delay corresponding to the third flow data, and the third flow data is less than the first preset data volume, 2≤M≤N, 1≤k≤M; according to the N(N-1) transmission parameters and the M small flow delays corresponding to the third flow data, it is judged whether the congestion control capability of the network to be tested is qualified.

[0008] In an exemplary embodiment of the present disclosure, the transmission parameter includes a transmission delay, and determining whether the N devices and switches connected to the N devices fail according to the N(N-1) transmission parameters includes:

[0009] Determine two or more devices corresponding to a transmission delay greater than a first preset delay among N(N-1) transmission delays;

[0010] If, among the transmission delays corresponding to a device among the two or more devices, the transmission delay exceeding a first preset ratio is greater than the first preset delay, marking the device as a suspicious device;

[0011] If the proportion of suspicious devices among the devices connected to a switch is greater than a second preset proportion, the switch is marked as a suspicious switch;

[0012] It is determined whether the suspicious device fails and whether the suspicious switch fails according to the suspicious device and the suspicious switch.

[0013] In an exemplary embodiment of the present disclosure, judging whether the congestion control capability of the network to be tested is qualified according to the N(N-1) transmission parameters and the M small flow delays corresponding to the third traffic data includes:

[0014] If there is a transmission delay greater than a second preset delay among the N(N-1) transmission delays, it is determined that the congestion control capability of the network to be tested is unqualified.

[0015] In an exemplary embodiment of the present disclosure, the transmission parameter includes a transmission time length for completing the transmission of the first traffic data, the first traffic data is greater than a second preset data amount, and the second preset data amount is greater than the first preset data amount. According to the N (N-1) transmission parameters and the M small flow delays corresponding to the third traffic data, judging whether the congestion control capability of the network to be tested is qualified includes:

[0016] If at least one of the N(N-1) sending durations is greater than a first preset duration, it is determined that the congestion control capability of the network to be tested is unqualified.

[0017] In an exemplary embodiment of the present disclosure, judging whether the congestion control capability of the network to be tested is qualified according to the N(N-1) transmission parameters and the M small flow delays corresponding to the third traffic data includes:

[0018] If at least one small flow delay among the M small flow delays is greater than a third preset delay, it is determined that the congestion control capability of the network to be tested is unqualified.

[0019] In an exemplary embodiment of the present disclosure, after marking a failed switch as a failed switch, marking a device connected to the failed switch as a failed device, and marking a failed device as a failed device, the method further includes:

[0020] In response to a message indicating that the switch accesses the network to be tested, an identifier of the switch is determined;

[0021] If the identifier of the switch corresponds to the identifier of the faulty switch, control the M devices without faults in the network to be tested and the device connected to the faulty switch to mutually send the first flow data to obtain a plurality of transmission parameters;

[0022] If it is determined according to the multiple transmission parameters that the faulty switch has recovered to normal, the faulty switch is marked as a normal switch, the device connected to the faulty switch is marked as a normal device, and the number M of the normal devices is updated.

[0023] In an exemplary embodiment of the present disclosure, after marking a failed switch as a failed switch, marking a device connected to the failed switch as a failed device, and marking a failed device as a failed device, the method further includes:

[0024] In response to a message that a device accesses the network to be tested, an identifier of the device is determined;

[0025] If the identifier of the device corresponds to the identifier of the faulty device, control the M devices without faults in the network to be tested and the faulty device to mutually send the first traffic data to obtain the transmission parameters corresponding to the faulty device;

[0026] If it is determined that the faulty device has recovered to normal according to the transmission parameters corresponding to the faulty device, the faulty device is marked as a normal device, and the number M of normal devices is updated.

[0027] According to a second aspect of an embodiment of the present disclosure, there is provided an electronic device, comprising: a memory; and a processor coupled to the memory, wherein the processor is configured to execute any one of the methods described above based on instructions stored in the memory.

[0028] According to a third aspect of the present disclosure, a computer-readable storage medium is provided, on which a program is stored, and when the program is executed by a processor, the congestion control capability testing method as described in any one of the above items is implemented.

[0029] According to a fourth aspect of the present disclosure, a computer program product is provided, comprising a computer program, wherein when the computer program is executed by a processor, the steps of any of the above methods are implemented.

[0030] The disclosed embodiment first controls the devices in the network to be tested to perform point-to-point testing to eliminate device failures and switch failures, evaluates the basic status of the network, and preliminarily determines obvious unqualified congestion control capabilities. It can quickly identify unqualified congestion control capabilities without accessing the switch, thereby improving the test efficiency of the congestion control capabilities. In addition, by performing a delay test in a many-to-one congestion scenario on a non-faulty device, it is precisely determined whether the congestion control capabilities of the network to be tested are qualified, and the queue processing capabilities of the switch can be measured without accessing the switch, thereby accurately implementing the test of the congestion control capabilities without accessing the switch.

[0031] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] The accompanying drawings herein are incorporated into the specification and constitute a part of the specification, illustrate embodiments consistent with the present disclosure, and together with the specification are used to explain the principles of the present disclosure. Obviously, the accompanying drawings described below are only some embodiments of the present disclosure, and for ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without creative work.

[0033] Figure 1 is a flow chart of a congestion control capability testing method in an exemplary embodiment of the present disclosure.

[0034] Figure 2 is a schematic diagram of a network to be tested in an exemplary embodiment of the present disclosure.

[0035] Figure 3 It is a sub-flowchart of step S3 in the exemplary embodiment of the present disclosure.

[0036] Figure 4 4 is a flowchart of updating the number of devices after step S3 in the exemplary embodiment of the present disclosure.

[0037] Figure 5 4 is a flowchart of updating the number of devices after step S3 in the exemplary embodiment of the present disclosure.

[0038] Figure 6 It is a schematic diagram of performing a small flow delay test in an exemplary embodiment of the present disclosure.

[0039] Figure 7 It is a schematic diagram of a test flow in an exemplary embodiment of the present disclosure.

[0040] Figure 8 is a block diagram of an electronic device in an exemplary embodiment of the present disclosure. DETAILED DESCRIPTION

[0041] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in a variety of forms and should not be construed as being limited to the examples set forth herein; on the contrary, these embodiments are provided so that the present disclosure will be more comprehensive and complete, and the concepts of the example embodiments are fully conveyed to those skilled in the art. The described features, structures, or characteristics may be combined in one or more embodiments in any suitable manner. In the following description, many specific details are provided to provide a full understanding of the embodiments of the present disclosure. However, those skilled in the art will appreciate that the technical solutions of the present disclosure may be practiced while omitting one or more of the specific details, or other methods, components, devices, steps, etc. may be adopted. In other cases, known technical solutions are not shown or described in detail to avoid obscuring various aspects of the present disclosure.

[0042] In addition, the accompanying drawings are only schematic diagrams of the present disclosure, and the same reference numerals in the drawings represent the same or similar parts, so their repeated description will be omitted. Some of the block diagrams shown in the accompanying drawings are functional entities, which do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software form, or implemented in one or more hardware modules or integrated circuits, or implemented in different networks and / or processor devices and / or microcontroller devices.

[0043] The exemplary embodiments of the present disclosure are described in detail below with reference to the accompanying drawings.

[0044] Figure 1 is a flow chart of a congestion control capability testing method in an exemplary embodiment of the present disclosure.

[0045] refer to Figure 1 , the congestion control capability testing method 100 may include:

[0046] Step S1, determining N devices in a network to be tested, wherein the N devices are connected to at least one switch;

[0047] Step S2, controlling the i-th device to send the first flow data to the j-th device to obtain the ij-th transmission parameter; controlling the j-th device to send the first flow data to the i-th device to obtain the ji-th transmission parameter, thereby obtaining N(N-1) transmission parameters, 1≤i≤N, 1≤j≤N, i≠j;

[0048] Step S3, determining whether the N devices and the switches connected to the N devices are faulty according to the N(N-1) transmission parameters, marking the faulty switches and devices as faulty switches and faulty devices respectively, and marking the devices connected to the faulty switches as faulty devices;

[0049] Step S4, among the M devices of the N devices except the faulty device, control M-2 devices to send the second flow data to the kth device, and one device to send the second flow data and the third flow data to the kth device to obtain the kth small flow delay corresponding to the third flow data, the third flow data is less than the first preset data volume, 2≤M≤N, 1≤k≤M;

[0050] Step S5: judging whether the congestion control capability of the network to be tested is qualified according to the N(N-1) transmission parameters and the M small flow delays corresponding to the third traffic data.

[0051] The disclosed embodiment first controls the devices in the network to be tested to perform point-to-point testing to eliminate device failures and switch failures, evaluates the basic status of the network, and preliminarily determines obvious unqualified congestion control capabilities. It can quickly identify unqualified congestion control capabilities without accessing the switch, thereby improving the test efficiency of the congestion control capabilities. In addition, by performing a delay test in a many-to-one congestion scenario on a non-faulty device, it is precisely determined whether the congestion control capabilities of the network to be tested are qualified, and the queue processing capabilities of the switch can be measured without accessing the switch, thereby accurately implementing the test of the congestion control capabilities without accessing the switch.

[0052] Next, each step of the congestion control capability testing method 100 is described in detail.

[0053] In step S1, N devices in a network to be tested are determined, and the N devices are connected to at least one switch.

[0054] Figure 2 is a schematic diagram of a network to be tested in an exemplary embodiment of the present disclosure.

[0055] refer to Figure 2 The network 200 to be tested may include at least one switch 21, each switch 21 is connected to at least one device 22, and the number of devices in the network 200 to be tested is N, where N≥1. The devices 22 may be various computing nodes, storage devices, and network-attached devices, and the devices 22 may communicate with each other through the switches 21. The switches 21 are connected to each other in communication (directly or through an upper-layer switch such as a core switch).

[0056] In an exemplary embodiment, the network to be tested 200 is, for example, an RDMA (Remote Direct Memory Access) network of an intelligent computing center or a storage center. RDMA network is a high-performance network communication technology that allows computers to directly transfer data between the memories of different nodes without intervention from the operating system kernel, greatly reducing data transmission latency and improving transmission efficiency.

[0057] When the network 200 to be tested is an RDMA network, the switch 21 can identify and process RDMA data packets, and quickly forward the data packets to the device 22 according to the network topology and traffic load. The device 22 connected to each switch 21 can be a server with powerful computing capabilities, which is equipped with a high-performance processor and a large-capacity memory and is specially used to process complex computing tasks; it can also be a mass storage device, such as a disk array, etc., for storing massive data resources.

[0058] Due to the stringent requirements of the RDMA network on performance and stability, it is necessary to configure a congestion control algorithm for the switch 21 and the device 22 to ensure the data transmission performance of the entire network. The congestion control algorithm is a key mechanism to prevent the network from experiencing performance degradation or even crashing due to excessive data traffic.

[0059] At the switch 21 level, its congestion control algorithm monitors the traffic load of each port. For example, the number of data packets received, byte flow, queue length and other parameters of the port per unit time are counted. When it is found that the traffic of a port is close to or exceeds its carrying capacity, congestion control is started, such as prioritizing the data packets entering the port to ensure that high-priority RDMA traffic (such as data transmission related to real-time computing tasks) can pass first, while low-priority traffic (such as some background data synchronization tasks) is appropriately delayed or limited. At the same time, the congestion control algorithm of switch 21 can also exchange information with adjacent switches, coordinately adjust the traffic path, and direct part of the traffic to links with lighter loads to balance the load of the entire network.

[0060] At the device 22 level, its congestion control algorithm focuses on its own sending and receiving buffer management and the response to network congestion signals. At the sending end, device 22 dynamically adjusts the sending rate based on the occupancy of its own buffer and the congestion feedback received from the network (such as congestion notifications sent by switch 21 or indirect perception of congestion by detecting changes in the delay of data packets). When the buffer is about to fill up or the network shows signs of congestion, device 22 reduces the sending rate to avoid further aggravating network congestion. At the receiving end, device 22 processes the received data by allocating memory resources to prevent data loss due to overflow of the receiving buffer. For example, when the amount of received data suddenly increases, device 22 can temporarily apply for more memory space or pre-process the data to speed up the transfer of data from the buffer.

[0061] In the RDMA network, the congestion control algorithms of switch 21 and device 22 cooperate and work together, just like the "traffic police" of the network, always monitoring the "traffic flow" of the network to ensure that data can be transmitted smoothly and efficiently in the network, thereby providing a stable and reliable network environment for various complex tasks of the intelligent computing center and storage center, ensuring the continuous and stable operation of key businesses such as large-scale parallel computing, massive data storage and reading, and enabling the entire RDMA network to give full play to its high-performance advantages.

[0062] Therefore, as the congestion control algorithm is updated, it is necessary to test the congestion control capability of the congestion control algorithm configured in the network to be tested 200 to ensure that the congestion control algorithm can meet the service requirements.

[0063] In step S1, for the network 200 to be tested, its topology structure needs to be sorted out and recorded first, and the connection relationship between each switch 21 and each device 22, including the port information of the connection, etc., needs to be clarified. At the same time, the basic configuration information of each device 22 needs to be collected, such as the supported RDMA protocol version, network card parameters, memory configuration, etc. After determining the switches 21 and devices 22 involved in the test in the network 200 to be tested, the switches 21 and devices 22 need to be configured for testing in order to implement subsequent point-to-point device testing and many-to-one congestion scenario small flow testing.

[0064] In an exemplary embodiment, the test method of the embodiment of the present disclosure can be implemented by one device 22 among N devices 22, or by a dedicated test device connected to each switch 21. Regardless of the device used for implementation, the tester can input test configuration information to the device executing the method 100 before the test, and the test configuration information includes, for example, the management port IP address, RDMA port IP address, and test result saving path of each device 22. Since the method of the embodiment of the present disclosure is implemented without accessing the switch, it is sufficient to ensure that the communication connection between the device executing the method 100 and each switch 21 is normal, and there is no need to set the switch 21.

[0065] In addition, it is also necessary to set the traffic type (such as write, send, read type), data volume (such as how many bytes (Byte), bits (bit)), transmission protocol (TCP, UDP, etc.) and other related parameters (such as data packet size) of the traffic data sent by device 22.

[0066] In the embodiment of the present disclosure, the test is performed by controlling the flow data of a fixed data volume transmitted between the devices 22. In the same test, the data volume of the flow data transmitted between the devices 22 is the same. Therefore, the data volume of the corresponding flow data can be preset according to the test type.

[0067] In an exemplary embodiment, multiple tests can be set for the same test, and each test corresponds to a traffic type. For example, when performing a transmission delay test, the transmission delay of sending the first traffic data of the write type between each device 22, the transmission delay of sending the first traffic data of the send type between each other, and the transmission delay of sending the first traffic data of the read type between each other can be tested three times. To this end, three types of first traffic data can be set, and each type of first traffic data corresponds to a traffic type. Since the comparison of transmission delays is between the same traffic type, the data volume of the first traffic data of different traffic types can be the same or different, as described in the subsequent embodiments.

[0068] Finally, the serial number of each device 22 can also be set to achieve test control later. For example, the identifiers of N devices 22 are written into a list or array, and these identifiers are sorted according to certain rules. The sorting method can be based on the physical location of the device, performance parameters, or hierarchical relationship in the network topology.

[0069] When sorting based on physical location, if the devices are distributed in the computer room according to the locations of cabinets and racks, serial numbers can be assigned to the devices in order from left to right and from top to bottom. In this way, when performing regionalized network testing, a group of devices in adjacent or specific areas can be easily selected for targeted testing, and possible local network problems can be quickly located, such as communication anomalies between devices in a cabinet.

[0070] In addition, you can also sort by performance parameters, putting devices with strong processing power, large memory, and high network interface speed in front and devices with relatively weak performance in the back. When simulating congestion scenarios, you can clearly observe the collaborative work between high-performance devices and low-performance devices based on test data, and whether the allocation of network resources between devices with different performance is reasonable.

[0071] Sorting by the hierarchical relationship in the network topology is suitable for complex network architectures, such as the division of devices in the core layer, aggregation layer, and access layer. Put the core layer devices at the front of the list, the aggregation layer devices next, and the access layer devices last, so that when testing the network's hierarchical architecture performance, data flow, and interactions between different layers, it can be carried out in an orderly manner.

[0072] After the serial number of the device is determined and recorded in a list or array, during the test control process, the specific device can be quickly located according to the serial number, and individual parameter configuration, traffic sending and receiving control, status monitoring and other operations can be performed on it. For example, when conducting a concurrent streaming test on multiple devices, the streaming process of the devices can be started in sequence according to the serial number to ensure the orderliness and accuracy of the test; or when a fault is detected in a certain area of ​​the network, the faulty device and its surrounding connected devices can be quickly checked according to the device serial number, improving the efficiency of fault diagnosis and repair, ensuring the efficient and stable advancement of the entire network testing work, and providing a solid foundation for network performance evaluation and optimization in complex network environments such as intelligent computing centers and storage centers.

[0073] After it is determined that the relevant test settings of the device 22 participating in the test are configured, the process may proceed to step S2 to start the point-to-point test.

[0074] In step S2, the i-th device is controlled to send the first traffic data to the j-th device to obtain the ij-th transmission parameter; the j-th device is controlled to send the first traffic data to the i-th device to obtain the ji-th transmission parameter, thereby obtaining N(N-1) transmission parameters, 1≤i≤N, 1≤j≤N, i≠j.

[0075] Step S2 means that, in a test type, point-to-point unidirectional communication is performed between N devices in pairs to obtain transmission parameters corresponding to N (N-1) point-to-point communications.

[0076] In an exemplary embodiment, the transmission parameter includes a transmission delay, and the test type includes testing the transmission delays in two directions corresponding to each other between N devices. In such a test, the traffic type of the first traffic data can be changed.

[0077] For example, to test the transmission delay, first set the first traffic data to the read type, and then set the data volume of the first traffic data. The data volume of the first traffic data can be flexibly adjusted according to the network properties, network functions and actual application scenario requirements of the network to be tested. Finally, according to the serial number of each device, the devices communicate with each other, and the ijth transmission delay is recorded as the difference between the receiving time and the sending time of the first traffic data sent by the ith device to the jth device. The jth transmission delay is recorded as the difference between the receiving time and the sending time of the first traffic data sent by the jth device to the ith device. Then, switch to the next group of equipment for testing until the testing of N devices is completed, and N (N-1) transmission delays corresponding to the read type traffic are obtained.

[0078] Next, the first traffic data can be changed to the write type, and the devices can be tested again to obtain N (N-1) transmission delays corresponding to the write type traffic. And so on. According to the test requirements, other elements of the first traffic data can also be adjusted (the traffic type is only an example) to measure the transmission delay corresponding to each combination of elements.

[0079] Transmission delay can reflect the basic operation status of the current network. If some transmission delays are too long, it means that at least one of the equipment, switch, and congestion control algorithm is abnormal. Please refer to the subsequent description for detailed judgment logic.

[0080] In an exemplary embodiment, the transmission parameters include the transmission time for the device to complete the transmission of the first traffic data. At this time, the data volume of the first traffic data needs to be set to be fixed and large, for example, larger than the second preset data volume, so as to facilitate the measurement of the transmission time for sending the first traffic data. The transmission time is used for the network bandwidth of the network to be tested under the current congestion control algorithm. The congestion control algorithm adjusts the traffic transmission rate of each device according to the network bandwidth.

[0081] In the disclosed embodiment, the sending time of the first flow data with a fixed data volume is tested by the device, which can reflect the sending rate of the device, thereby determining whether the congestion control algorithm automatically adjusts the sending rate, so as to determine whether the congestion control algorithm has an impact on the network bandwidth. Since the test is performed through one-way communication between two devices, if the data volume of the first flow data is not too large, it will not cause network congestion, and the congestion control algorithm should not be triggered to adjust the sending rate. Therefore, if a certain sending time exceeds the first preset time, it means that the congestion control algorithm has adjusted the sending rate, which means that the congestion control algorithm is unqualified.

[0082] The sending duration test can usually be performed for different types of traffic, such as the above-mentioned read type traffic, write type traffic, etc., which will not be described in detail here.

[0083] It should be noted that during the test process, it is necessary to ensure that the environment of the network to be tested is stable, eliminate other external interference factors, such as other irrelevant traffic bursts, network resource occupation by other devices, and potential impacts in complex network topologies, and ensure that each device is not running other more complex tasks (for example, the total CPU or memory occupancy rate exceeds 10%), so as to avoid other factors interfering with the judgment of the test results.

[0084] The transmission delay test and the network bandwidth (sending duration) test can be performed either alone or simultaneously (simultaneously measuring the sending duration and the transmission delay for the first traffic data), or sequentially (e.g., testing the transmission delay first and then testing the sending duration). In the disclosed embodiment, the transmission delay and sending duration tests are performed sequentially, and the test accuracy is relatively high.

[0085] In the above transmission delay test and sending duration test, since only one device sends unidirectional traffic and one device receives traffic at a time, the basic parameters of the network can be tested when there are fewer transmission tasks, fewer concurrent connections, and less data packet transmission frequency.

[0086] When devices communicate with each other, the network is relatively idle, that is, when there are few transmission tasks and a small number of concurrent connections, the measured transmission parameters can more clearly reflect the health status of the device itself and the initial performance of the congestion control mechanism. The small number of concurrent connections means that there are limited channels for data exchange at the same time. If an abnormality occurs at this time, it is easier to locate the problem of a specific device or connection link. Since the two-to-two transmissions have a low frequency of data packet transmission, mutual interference during data transmission can be reduced, making the transmission of a single data packet easier to observe and analyze, such as whether the transmission delay is stable. These transmission parameters are very critical for judging whether the device is working properly and whether there are abnormalities in congestion control. When the network is idle, if the congestion control capability is abnormal, it can be more intuitively and quickly discovered in this relatively simple test environment.

[0087] Therefore, if there is a problem with transmission parameters such as transmission delay or sending duration, in an environment without a complex network environment to conceal and mislead, it is highly likely that it is one of the three reasons: equipment failure, switch failure, and unsatisfactory congestion control capability. The setting of step S2 can quickly locate the fault, discover the fault as early as possible, and improve test efficiency.

[0088] In addition to the above-mentioned test transmission delay and transmission time (network bandwidth), other types of transmission parameters can also be tested to test the transmission parameters of each device in a network environment with fewer transmission tasks, fewer concurrent connections, and less packet transmission frequency, so as to determine device failures and intuitively and quickly detect abnormal congestion control capabilities. Those skilled in the art can set the types and quantities of transmission parameters according to test requirements, and the present disclosure is not limited thereto.

[0089] After measuring the transmission parameters, the faults can be simply screened according to the transmission parameters to find obvious problems as quickly as possible and improve test efficiency.

[0090] In step S3, whether the N devices and the switches connected to the N devices fail is determined based on the N(N-1) transmission parameters, the failed switches and devices are marked as failed switches and failed devices respectively, and the devices connected to the failed switches are marked as failed devices.

[0091] Figure 3 It is a sub-flowchart of step S3 in the exemplary embodiment of the present disclosure.

[0092] refer to Figure 3 In an exemplary embodiment, step S3 may include:

[0093] Step S31, determining two or more devices corresponding to a transmission delay greater than a first preset delay among N (N-1) transmission delays;

[0094] Step S32, if the transmission delay corresponding to a device among the two or more devices exceeds the first preset ratio and is greater than the first preset delay, mark the device as a suspicious device;

[0095] Step S33: if the proportion of suspicious devices among the devices connected to a switch is greater than a second preset proportion, mark the switch as a suspicious switch;

[0096] Step S34, determining whether the suspicious device is faulty and whether the suspicious switch is faulty based on the suspicious device and the suspicious switch.

[0097] As analyzed above, in a network environment with fewer transmission tasks, fewer concurrent connections, and a lower packet transmission frequency, if the transmission delay is large, it means that there is a high probability of at least one of the three problems: device failure, switch failure, and unqualified congestion control capability. Therefore, the first preset delay is first set to screen the transmission delay with problems.

[0098] The first preset delay can be determined based on reference factors such as the environment of the network to be tested, the type and performance of the equipment, the data volume of the first traffic data, etc. For example, a relatively reasonable transmission delay can be determined based on actual measurement results, which need to be obtained in a test of a network environment with a fault-free device and congestion control capability, and on this basis, the transmission delay corresponding to the abnormal situation can be determined, so as to reasonably determine the first preset delay.

[0099] In step S31, if a transmission delay exceeds the first preset delay, the two devices (sending device and receiving device) corresponding to the transmission delay can be marked as suspicious devices, and it is recorded that the device is suspicious when sending or receiving (because some devices may have normal sending functions and abnormal receiving functions, etc.). The reason why it is marked as a suspicious device rather than a faulty device is that some transmission anomalies may be caused by switch failures or congestion control capabilities, so it is only marked as suspicious in step S31.

[0100] Next, in step S32, the transmission delays corresponding to each suspicious device (the transmission delay as the receiver and the transmission delay as the sender) are queried, and the proportion of abnormal transmission delays is calculated. If most of the transmission delays corresponding to a suspicious device exceed the first preset delay (the proportion exceeds the first preset proportion), it means that the device is likely to be abnormal. The first preset proportion can be set higher, such as 80%, to improve the accuracy of judgment.

[0101] If the transmission delay corresponding to a suspicious device mostly does not exceed the first preset delay, other causes can be further checked.

[0102] In step S33, in the process of determining the switch failure, the devices connected to the switch are first summarized to determine the proportion of abnormal devices. If more than a second preset proportion of devices connected to a switch are abnormal devices, it means that the abnormality of these abnormal devices is most likely caused by the switch, and the switch can be marked as a suspicious switch.

[0103] Next, in step S34, further screening is performed based on the suspicious switches and suspicious devices.

[0104] In some embodiments, the method for determining the faulty device and the faulty switch based on the suspicious device and the suspicious switch is, for example, to temporarily interrupt the connection between the suspicious device and other devices, use the backup link (if any) or directly connect to the known normal switch port, restart the flow test with other normal devices, and observe whether its transmission delay returns to normal. If it returns to normal, it can be basically determined that the device is a faulty device, and the cause of its failure is most likely due to its own hardware or software configuration problems, such as network card failure, driver abnormality, etc.

[0105] For suspicious switches, select some devices connected to their ports, transfer the connections of these devices to another normally operating switch (provided that there is a spare switch available for deployment), conduct traffic testing again, and compare the transmission delay changes of these devices before and after the transfer. If the delay is significantly improved after the transfer, close to or reaching the expected value under a normal network environment, it can be determined that the switch is faulty, and the fault point may be in the switch's internal switching matrix, port module, or congestion control module.

[0106] In addition, clustering analysis technology can be introduced to assist in judgment. The relevant parameters of all devices and switches, such as the average transmission delay, standard deviation of transmission delay, flow rate, number of connected devices, etc., are used as feature vectors, and clustering algorithms (such as K-Means algorithm) are used for clustering. Normally working devices and switches are usually clustered in one or several clusters with similar characteristics, while suspicious devices and switches may be divided into other clusters due to their abnormal parameter performance. By observing the distribution within and between clusters, the faulty devices and faulty switches can be further confirmed. For example, if other devices in the cluster where a suspicious device is located also show similar problems such as high latency, low flow rate (high sending time), and the cluster is clearly distinguished from the normal cluster, then the possibility of failure of the device is higher; similarly, for a suspicious switch, if most of the devices connected to it are in the problem cluster, it can also provide strong evidence for judging its failure.

[0107] During the entire troubleshooting process, various test data can be automatically recorded and output (for example, through txt documents or to the screen), including detailed results of each flow test, configuration changes of equipment and switches, etc., to facilitate subsequent review and analysis, continuously optimize fault diagnosis methods, improve the efficiency and accuracy of network operation and maintenance, and ensure that the network under test runs stably and efficiently in various complex application scenarios, meeting the stringent requirements of network performance such as intelligent computing centers and storage centers.

[0108] After identifying the faulty device and the faulty switch, you can either directly cut the faulty device or the faulty switch out of the network to be tested, and only perform the next test based on the remaining M devices and switches that can ensure normal operation, or wait for a while to see if the faulty device or the faulty switch can be repaired, and then rejoin the network to be tested after repair.

[0109] Figure 4 4 is a flowchart of updating the number of devices after step S3 in the exemplary embodiment of the present disclosure.

[0110] refer to Figure 4 , the process of updating the number of devices may include:

[0111] Step S301, responding to a message that the switch accesses the network to be tested, and determining an identifier of the switch;

[0112] Step S302: If the identifier of the switch corresponds to the identifier of the faulty switch, control the M healthy devices in the network to be tested and the device connected to the faulty switch to mutually send first flow data to obtain multiple transmission parameters;

[0113] Step S303: if it is determined according to multiple transmission parameters that the faulty switch has recovered to normal, the faulty switch is marked as a normal switch, the devices connected to the faulty switch are marked as normal devices, and the number M of normal devices is updated.

[0114] Figure 4 In the illustrated embodiment, if the faulty switch is repaired and then rejoins the network to be tested, it can be determined that it is a repaired faulty switch based on the identifier of the switch, and then the detection program is started to control the devices connected to it to perform pairwise tests with other normal devices in the network to be tested in the form of step S2 to determine whether the transmission delay of the devices connected to the switch has returned to normal. For example, when the transmission delays corresponding to these devices are all lower than the first preset delay, it is determined that the devices and the switch have returned to normal. Then, the marking status of the switch and its connected devices is updated, and the number of fault-free devices M is updated.

[0115] Figure 5 4 is a flowchart of updating the number of devices after step S3 in the exemplary embodiment of the present disclosure.

[0116] refer to Figure 5 , the process of updating the number of devices may also include:

[0117] Step S304, responding to the message that the device has accessed the network to be tested, and determining the identifier of the device;

[0118] Step S305: If the identifier of the device corresponds to the identifier of the faulty device, control the M devices without faults in the network to be tested to send first flow data to the faulty device to obtain transmission parameters corresponding to the faulty device;

[0119] Step S306: If it is determined that the faulty device has recovered according to the transmission parameters corresponding to the faulty device, the faulty device is marked as a normal device, and the number M of normal devices is updated.

[0120] exist Figure 5 In the illustrated embodiment, if the faulty device is repaired and then rejoins the network to be tested, a transmission parameter test may be initiated based on the identifier to determine whether the device has been repaired. If it is determined that the device has been repaired (for example, its corresponding transmission delay does not exceed the first preset delay), the status of the device and the number M of fault-free devices are updated.

[0121] By determining the faulty device and switch based on the transmission parameters and updating the device records after the faulty device and switch are repaired, abnormal test results caused by device failure and switch failure can be eliminated in a simple test environment, and subsequent tests can be performed in a normal device environment to improve test efficiency and test accuracy.

[0122] Since the embodiment of the present disclosure needs to solve the problem of being unable to access the switch, the inventors, through analysis and testing, determined to use a small flow test to measure the congestion control capability of the system.

[0123] That is, in step S4, among the M devices of the N devices except the faulty device, M-2 devices are controlled to send the second flow data to the kth device, and one device sends the second flow data and the third flow data to the kth device to obtain the kth small flow delay corresponding to the third flow data, and the third flow data is less than the first preset data volume, 2≤M≤N, 1≤k≤M.

[0124] The first preset data volume may be relatively small, so as to limit the third traffic data to a “small flow”.

[0125] Small flows (data flows with small data packets and short duration) refer to data flows with relatively small data volumes and specific traffic characteristics in network data transmission. When a large number of large flows are transmitted in the network, they may occupy the cache space and bandwidth resources of the network equipment, causing the small flows to face queuing or delayed processing during the transmission process. Therefore, when the small flows pass through the switch queue, their delay is mainly composed of the waiting time in the queue and the transmission time. When the length of the switch queue increases, the waiting time of the small flow after entering the queue will become longer, resulting in an increase in the delay of the small flow. Therefore, the length of the switch queue can be indirectly reflected by monitoring the delay of the small flow. In step S4, in the scenario of actively causing congestion (controlling multiple devices to flow to one device), obtaining the delay data of the small flow superimposed on the flow traffic can reflect the length of the current switch queue when the network to be tested is in a network congestion state, thereby evaluating the congestion control ability of the algorithm. At the same time, avoiding access to the switch greatly simplifies the deployment difficulty.

[0126] Figure 6 It is a schematic diagram of performing a small flow delay test in an exemplary embodiment of the present disclosure.

[0127] refer to Figure 6 ,Assume that there are two switches 211 and 212 in the network 200 to be tested, each switch is connected to three devices, a total of six devices 221-226, these six devices and the two switches are all fault-free, M=6.

[0128] In step S4, when performing a small flow delay test, first set device 221 as a receiving device, and devices 222-226 as sending devices to send the second flow data A2, thereby creating a network congestion environment. At the same time, set any one of devices 222-226 to superimpose the third flow data A3, i.e., a small flow, while sending the second flow data A2, so as to test the transmission delay of the third flow data, i.e., the small flow delay, and reflect the switch queue length of the network 200 under congestion scenario. Since the small flow is not limited by bandwidth, it will not further affect the bandwidth and aggravate congestion. Therefore, the processing speed of the switch for the small flow is mainly affected by its queue length, and the switch queue length can reflect the congestion control capability of the current congestion control algorithm.

[0129] After measuring the small flow delay corresponding to device 221 as a receiving device, continue to set device 222 as a receiving device, set device 221 and devices 223-226 as sending devices to send the second flow data. At the same time, set device 221 and any one of devices 223-226 to superimpose the third flow data, i.e., the small flow, while sending the second flow data, thereby measuring the small flow delay corresponding to device 222 as a receiving device.

[0130] Similarly, six small flow delays are measured. Since the six devices are connected to two switches respectively, these six tests and six small flow delays can reflect the queue lengths of the two switches in multiple directions and conduct a comprehensive test of the queue lengths of the switches.

[0131] After the test is completed, based on the above test result data, such as transmission delay, sending time, small flow delay, etc., it can be automatically output to the screen or file, and can also be automatically processed to automatically give the congestion control capability evaluation result of the current congestion control algorithm.

[0132] In step S5, whether the congestion control capability of the network to be tested is qualified is determined based on the N(N-1) transmission parameters and the M small flow delays corresponding to the third traffic data.

[0133] In an exemplary embodiment, if there is a transmission delay greater than a second preset delay among the N(N-1) transmission delays, it is determined that the congestion control capability of the network to be tested is unqualified.

[0134] In the above embodiment, the first preset delay is set to screen out devices and switches with problems in the sending and receiving mechanisms. The first preset delay can correspond to scenarios such as device failure and switch failure based on calculation or actual measurement.

[0135] In this embodiment, a second preset delay is set to identify the problem of unqualified congestion control capability. Compared with the first preset delay, the second preset delay can be set relatively loosely. Because the first preset delay mainly focuses on the abnormal increase in transmission delay caused by local hardware or software failures of devices and switches in normal operation, its purpose is to accurately locate individual devices or switch ports that may fail. The second preset delay is based on the overall congestion control of the network. Considering that a certain degree of load fluctuation and a reasonable delay range are allowed during normal operation of the network, when the transmission delay exceeds the second preset delay, it means that the network is already in a more serious congestion state and the congestion control mechanism fails to effectively intervene and adjust, resulting in a serious decline in overall network performance and failure to meet basic service quality requirements.

[0136] The determination of the second preset delay requires a comprehensive consideration of many factors. On the one hand, the design specifications and expected service levels of the network to be tested must be considered. For example, if the network to be tested is to support a real-time financial trading system that is extremely sensitive to latency, then the second preset delay must be set extremely low to ensure that network congestion will not have a substantial impact on the rapid execution of transactions under any circumstances; if it is for an ordinary corporate office network, its tolerance for latency is relatively high, then the second preset delay can be appropriately relaxed. On the other hand, it is necessary to analyze the historical performance data of the network. By monitoring the changes in the transmission delay of the network under different load conditions for a long time, a reasonable threshold is determined using statistical analysis methods, so that in normal business peak periods and other situations, as long as the congestion control mechanism operates normally, the transmission delay will not easily exceed the threshold.

[0137] By quickly screening out unqualified congestion control capabilities through the second preset delay, the efficiency of problem location can be improved. If the congestion control capability is determined to be unqualified based on the transmission delay, no subsequent processing and testing are required.

[0138] Of course, even if the transmission delay does not exceed the second preset delay, it does not mean that there is no problem with the congestion control capability, and further judgment is required in combination with other transmission parameters.

[0139] In an exemplary embodiment, if at least one of the N(N-1) transmission durations is greater than a first preset duration, it is determined that the congestion control capability of the network to be tested is unqualified.

[0140] The previous analysis shows that in the point-to-point test, when the data volume of the first transmission flow is controlled, network congestion will not occur, and the transmission time of each device for the first transmission flow should be relatively close. If the measured transmission time is longer than the first preset time, excluding equipment failure, it means that there is a problem with the congestion control mechanism, and it is determined that the congestion control capability is unqualified, and the current congestion control algorithm needs to be modified.

[0141] Furthermore, in the embodiment of the present disclosure, the congestion control capability is determined mainly based on the small flow delay in the congestion scenario. If at least one small flow delay among the M small flow delays is greater than the third preset delay, it is determined that the congestion control capability of the network under test is unqualified.

[0142] According to the analysis in the previous article, when a small flow (which can be understood as a data flow with a small data packet and a short duration) passes through the switch queue, its delay is mainly composed of the waiting time in the queue and the transmission time. When the length of the switch queue increases, the waiting time of the small flow after entering the queue will become longer, which will cause the small flow delay to increase. Therefore, the length of the switch queue can be indirectly reflected by monitoring the small flow delay. The small flow delay reflects the length of the switch queue. If any small flow delay exceeds the third preset delay, it can be said that the switch queue length in the transmission direction of the small flow is too long and the congestion control capability is unqualified. The third preset delay can be set according to factors such as the amount of data of the third traffic data, the number of devices connected to the system, the performance of the devices and switches, etc., which will not be repeated here.

[0143] Figure 7 It is a schematic diagram of a test flow in an exemplary embodiment of the present disclosure.

[0144] refer to Figure 7 In step S71, firstly, the configuration information of the test node, ie, the device of the network to be tested, is obtained.

[0145] In step S72, a point-to-point bandwidth test is performed to determine the transmission time of the device to send a fixed amount of traffic data. In the point-to-point test, two loops, an outer loop and an inner loop, are required. The outer loop includes recording the number of outer loops i, starting the server i required for the test (i.e., the i-th device); the inner loop includes recording the number of inner loops j, starting the server j required for the test (i.e., the j-th device), and outputting the test results. For example, in the outer loop, a device i is selected, the corresponding server is started, and the inner loop corresponding to the device i is entered; in the inner loop, the other N-1 devices are selected respectively to communicate with the device i, and each device communicates with the device i twice. The corresponding transmission parameters are recorded and output for each communication. After the N-1 devices have completed the communication, the current inner loop ends, returns to the outer loop, selects the device i+1, enters the inner loop corresponding to the device i+1, and realizes 2*(N-1) communications. And so on.

[0146] In step S73, a point-to-point delay test is performed to test the delay of transmitting the first flow data between two devices. The point-to-point process also enters the outer loop and inner loop mentioned above, which will not be described in detail.

[0147] In step S74, a small flow delay test in a congested scenario is performed, which specifically includes:

[0148] Step S741, start the many-to-one incast background traffic, that is, control M-1 devices to send the second traffic data to one device at the same time. Incast traffic is a special traffic mode, which usually appears in scenarios such as data center networks. When multiple senders send incast traffic to one receiver at the same time, the queue state of the switch is easily affected.

[0149] Step S742, start small flow superposition, control any one of the M-1 devices to superimpose the third flow data on the second flow data, the third flow data is a small flow.

[0150] Step S742: Record the small flow delay corresponding to each node / device.

[0151] In this embodiment, the node bandwidth can be obtained through the output of perftest.

[0152] During the test, if the RDMA network is tested, the specific RDMA operation (send, read, write, etc.) used in each test, the number of QPs (Queue Pairs), and the traffic direction are all configurable by the operation and maintenance personnel. Among them, QP is the basic unit of communication under the RDMA architecture, consisting of a send queue and a receive queue, which is used to achieve efficient data transmission between different nodes (such as servers and other devices). Each QP corresponds to a specific source and destination, and can be regarded as a "channel" specially opened for data interaction between two nodes.

[0153] The above process can be implemented through virtual modules such as an automated testing module, a test result acquisition module, and a result output module, and the present disclosure does not impose any special restrictions on this.

[0154] When the test report is automatically output, the test report may include RDMA communication types such as write, send, read, the amount of traffic data, the bandwidth test results of each node (device) (sending time), transmission delay and fairness of bandwidth test results (distribution), bottleneck switch queue conditions, etc. It may also include information such as average transmission delay, 99% tail delay, and the type of background traffic (second traffic data) corresponding to small flow delay.

[0155] In summary, the disclosed embodiments can implement a congestion control evaluation scheme in a physical environment without the need for switch login information (the existing scheme requires configuring the switch login information, logging into the switch, and collecting data through the SNMP protocol. Since it is usually difficult for the end-side network card operation and maintenance personnel to obtain the switch login permission, this scheme is difficult to deploy in practice). By using the scheme of indirectly perceiving the queuing status of the switch through the small flow delay in the congestion scenario, a pure end-side deployment of the congestion control capability test can be achieved, which is highly feasible. In addition, by setting up automation to evaluate the basic point-to-point capabilities in the network to be tested, it is convenient to quickly discover and locate problem nodes. At the same time, a comprehensive evaluation of the congestion control capability of the congestion control algorithm for different communication primitives (traffic types) and different message lengths (data volume) is achieved. Finally, the operation and maintenance personnel only need to perform simple configuration of the relevant configuration information on the end side to obtain a complete test report, which can greatly improve the efficiency and accuracy of the evaluation and verification.

[0156] Therefore, the embodiments of the present disclosure can complete an efficient and accurate evaluation of the congestion control capability of the congestion control algorithm currently used in the network to be tested through simple settings, tests and judgments, without logging into the switch, and only relying on terminal devices.

[0157] It should be noted that, although several modules or units of the device for action execution are mentioned in the above detailed description, this division is not mandatory. In fact, according to the embodiments of the present disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. On the contrary, the features and functions of one module or unit described above can be further divided into multiple modules or units to be embodied.

[0158] In an exemplary embodiment of the present disclosure, an electronic device capable of implementing the above method is also provided.

[0159] It will be appreciated by those skilled in the art that various aspects of the present invention may be implemented as a system, method or program product. Therefore, various aspects of the present invention may be specifically implemented in the following forms, namely: a complete hardware implementation, a complete software implementation (including firmware, microcode, etc.), or a combination of hardware and software, which may be collectively referred to herein as a "circuit", "module" or "system".

[0160] Refer to the following Figure 8 An electronic device 800 according to this embodiment of the present invention will be described. Figure 8The electronic device 800 shown is only an example and should not limit the functions and scope of use of the embodiments of the present invention. The electronic device 800 can be any device 22 in the network 200 to be tested, or a dedicated test device that is specially set and independent of each device 22. The electronic device 800 is used to execute the method in the above embodiment.

[0161] like Figure 8 As shown, the electronic device 800 is in the form of a general computing device. The components of the electronic device 800 may include but are not limited to: at least one processing unit 810, at least one storage unit 820, and a bus 830 connecting different system components (including the storage unit 820 and the processing unit 810).

[0162] The storage unit stores program codes, which can be executed by the processing unit 810, so that the processing unit 810 performs the steps according to various exemplary embodiments of the present invention described in the above “Exemplary Method” section of this specification. For example, the processing unit 810 can perform the method shown in the embodiment of the present disclosure.

[0163] The storage unit 820 may include a readable medium in the form of a volatile storage unit, such as a random access storage unit (RAM) 8201 and / or a cache storage unit 8202 , and may further include a read-only storage unit (ROM) 8203 .

[0164] The storage unit 820 may also include a program / utility 8204 having a set (at least one) of program modules 8205, such program modules 8205 including but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which or some combination may include an implementation of a network environment.

[0165] Bus 830 may represent one or more of several types of bus structures, including a memory unit bus or memory unit controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of a variety of bus architectures.

[0166] The electronic device 800 may also communicate with one or more external devices 900 (e.g., keyboards, pointing devices, Bluetooth devices, etc.), may also communicate with one or more devices that enable a user to interact with the electronic device 800, and / or communicate with any device that enables the electronic device 800 to communicate with one or more other computing devices (e.g., routers, modems, etc.). Such communication may be performed via an input / output (I / O) interface 850. Furthermore, the electronic device 800 may also communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via a network adapter 860. As shown, the network adapter 860 communicates with other modules of the electronic device 800 via a bus 830. It should be understood that, although not shown in the figure, other hardware and / or software modules may be used in conjunction with the electronic device 800, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, etc.

[0167] Through the description of the above implementation, it is easy for those skilled in the art to understand that the example implementation described here can be implemented by software, or by software combined with necessary hardware. Therefore, the technical solution according to the implementation of the present disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, including several instructions to enable a computing device (which can be a personal computer, a server, a terminal device, or a network device, etc.) to execute the method according to the implementation of the present disclosure.

[0168] In an exemplary embodiment of the present disclosure, a computer-readable storage medium is also provided, on which a program product capable of implementing the above method of the present specification is stored. In some possible implementations, various aspects of the present invention can also be implemented in the form of a program product, which includes a program code, and when the program product is run on a terminal device, the program code is used to enable the terminal device to execute the steps according to various exemplary embodiments of the present invention described in the above "Exemplary Method" section of the present specification.

[0169] The program product for implementing the above method according to an embodiment of the present invention can adopt a portable compact disk read-only memory (CD-ROM) and include program code, and can be run on a terminal device, such as a personal computer. However, the program product of the present invention is not limited thereto, and in this document, a readable storage medium can be any tangible medium containing or storing a program, which can be used by or in combination with an instruction execution system, an apparatus or a device.

[0170] The program product may use any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples (non-exhaustive list) of readable storage media include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0171] Computer readable signal media may include data signals propagated in baseband or as part of a carrier wave, in which readable program code is carried. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Readable signal media may also be any readable medium other than a readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0172] The program code embodied on the readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wired, optical cable, RF, etc., or any suitable combination of the foregoing.

[0173] Program code for performing the operations of the present invention may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, C++, etc., and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user computing device, partially on the user device, as a separate software package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving a remote computing device, the remote computing device may be connected to the user computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computing device (e.g., through the Internet using an Internet service provider).

[0174] In addition, the above-mentioned figures are only schematic illustrations of the processes included in the method according to an exemplary embodiment of the present invention, and are not intended to be limiting. It is easy to understand that the processes shown in the above-mentioned figures do not indicate or limit the time sequence of these processes. In addition, it is also easy to understand that these processes can be performed synchronously or asynchronously, for example, in multiple modules.

[0175] Those skilled in the art will readily appreciate other embodiments of the present disclosure after considering the specification and practicing the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the present disclosure that follow the general principles of the present disclosure and include common knowledge or customary techniques in the art that are not disclosed in the present disclosure. The specification and examples are to be considered exemplary only, and the true scope and concept of the present disclosure are indicated by the claims.

Claims

1. A congestion control capability testing method, characterized in that: include: Determine N devices in the network to be tested, wherein the N devices are connected to at least one switch; Control the i-th device to send the first flow data to the j-th device to obtain the ij-th transmission parameter; control the j-th device to send the first flow data to the i-th device to obtain the ji-th transmission parameter, thereby obtaining N(N-1) transmission parameters, 1≤i≤N, 1≤j≤N, i≠j; Determine whether the N devices and the switches connected to the N devices are faulty according to the N(N-1) transmission parameters, mark the faulty switches and devices as faulty switches and faulty devices respectively, and mark the devices connected to the faulty switches as faulty devices; Among the M devices of the N devices except the faulty device, control M-2 devices to send the second flow data to the kth device, and one device to send the second flow data and the third flow data to the kth device to obtain the kth small flow delay corresponding to the third flow data, the third flow data is less than the first preset data volume, 2≤M≤N, 1≤k≤M; Whether the congestion control capability of the network to be tested is qualified is determined according to the N(N-1) transmission parameters and the M small flow delays corresponding to the third traffic data.

2. The congestion control capability testing method according to claim 1, characterized in that: The transmission parameters include transmission delay, and determining whether the N devices and switches connected to the N devices fail according to the N(N-1) transmission parameters includes: Determine two or more devices corresponding to a transmission delay greater than a first preset delay among N(N-1) transmission delays; If, among the transmission delays corresponding to a device among the two or more devices, the transmission delay exceeding a first preset ratio is greater than the first preset delay, marking the device as a suspicious device; If the proportion of suspicious devices among the devices connected to a switch is greater than a second preset proportion, the switch is marked as a suspicious switch; It is determined whether the suspicious device fails and whether the suspicious switch fails according to the suspicious device and the suspicious switch.

3. The congestion control capability testing method according to claim 2, characterized in that: Judging whether the congestion control capability of the network to be tested is qualified according to the N(N-1) transmission parameters and the M small flow delays corresponding to the third traffic data includes: If there is a transmission delay greater than a second preset delay among the N(N-1) transmission delays, it is determined that the congestion control capability of the network to be tested is unqualified.

4. The congestion control capability testing method according to claim 1, characterized in that: The transmission parameter includes a transmission time length for completing the transmission of the first traffic data, the first traffic data is greater than a second preset data volume, and the second preset data volume is greater than the first preset data volume, and judging whether the congestion control capability of the network to be tested is qualified according to the N (N-1) transmission parameters and the M small flow delays corresponding to the third traffic data includes: If at least one of the N(N-1) sending durations is greater than a first preset duration, it is determined that the congestion control capability of the network to be tested is unqualified.

5. The congestion control capability testing method according to claim 1, characterized in that: Judging whether the congestion control capability of the network to be tested is qualified according to the N(N-1) transmission parameters and the M small flow delays corresponding to the third traffic data includes: If at least one small flow delay among the M small flow delays is greater than a third preset delay, it is determined that the congestion control capability of the network to be tested is unqualified.

6. The congestion control capability testing method according to claim 1, characterized in that: After marking the failed switch as a failed switch, marking the device connected to the failed switch as a failed device, and marking the failed device as a failed device, the method further includes: In response to a message indicating that the switch accesses the network to be tested, an identifier of the switch is determined; If the identifier of the switch corresponds to the identifier of the faulty switch, control the M devices without faults in the network to be tested and the device connected to the faulty switch to mutually send the first flow data to obtain a plurality of transmission parameters; If it is determined according to the multiple transmission parameters that the faulty switch has recovered to normal, the faulty switch is marked as a normal switch, the device connected to the faulty switch is marked as a normal device, and the number M of the normal devices is updated.

7. The congestion control capability testing method according to claim 1 or 6, characterized in that: After marking the failed switch as a failed switch, marking the device connected to the failed switch as a failed device, and marking the failed device as a failed device, the method further includes: In response to a message that a device accesses the network to be tested, an identifier of the device is determined; If the identifier of the device corresponds to the identifier of the faulty device, control the M devices without faults in the network to be tested and the faulty device to mutually send the first traffic data to obtain the transmission parameters corresponding to the faulty device; If it is determined that the faulty device has recovered to normal according to the transmission parameters corresponding to the faulty device, the faulty device is marked as a normal device, and the number M of normal devices is updated.

8. An electronic device, characterized in that: include: Memory; as well as A processor coupled to the memory, the processor being configured to execute the method according to any one of claims 1 to 6 based on instructions stored in the memory.

9. A computer-readable storage medium having a program stored thereon, wherein when the program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images