Congestion control capability test method and electronic device

Abstract

The present disclosure provides a congestion control capability test method and an electronic device. The method comprises: controlling an i-th device in N devices in a network under test to send first traffic data to a j-th device to obtain an ij-th transmission parameter; controlling the j-th device to send the first traffic data to the i-th device to obtain a ji-th transmission parameter, thereby obtaining N(N-1) transmission parameters; determining whether the N devices and a switch fail according to the N(N-1) transmission parameters; in M devices without failure, controlling M-2 devices to send second traffic data to a k-th device, and one device to send second traffic data and third traffic data to the k-th device to obtain a k-th small flow time delay corresponding to the third traffic data; and determining whether the congestion control capability of the network under test is qualified according to the N(N-1) transmission parameters and the M small flow time delays corresponding to the third traffic data. The present disclosure can test the congestion control capability without accessing the switch.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the field of Internet, in particular to a congestion control capability testing method and an electronic device. BACKGROUND

[0002] Currently, programmable network congestion control technology is increasingly mature, and the congestion control algorithm of RDMA network of a cluster of networks such as a computing center and a storage center is updated and iterated rapidly. After each iteration of the algorithm, 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, and the performance evaluation of the congestion control algorithm is a key link for verifying the performance of the algorithm.

[0003] In the related art, the congestion control capability of the algorithm needs to be determined by accessing the queue of the switch, but since the switch in the existing network is usually maintained by a dedicated person, the end-side network card operation and maintenance personnel usually cannot access it, which makes it difficult to deploy.

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

[0005] It should be noted that the information disclosed in the above background section is only used to strengthen the understanding of the background of the present disclosure, and therefore can include information that does not constitute prior art known to those of ordinary skill in the art. SUMMARY

[0006] The purpose of the present disclosure is to provide a congestion control capability testing method and an electronic device for automatically and accurately evaluating the congestion control capability of a network under test without accessing the switch.

[0007] According to a first aspect of the embodiments of the present disclosure, a congestion control capability testing method is provided, which comprises: determining N devices in a network to be tested, the N devices being connected to at least one switch; controlling an i-th device to send first traffic data to a j-th device to obtain an ij-th transmission parameter; controlling the j-th device to send the first traffic data to the i-th device to obtain a 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 fail according to the N(N-1) transmission parameters, marking the switches and devices that fail as faulty switches and faulty devices respectively, and marking the devices connected to the faulty switches as faulty devices; in M devices among the N devices excluding the faulty devices, controlling M-2 devices to send second traffic data to a k-th device, and one device to send the second traffic data and third traffic data to the k-th device to obtain a k-th small flow time delay corresponding to the third traffic data, the third traffic data being smaller than a first preset data amount, 2≤M≤N, 1≤k≤M; 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 time delays corresponding to the third traffic data.

[0008] In an exemplary embodiment of the present disclosure, the transmission parameters comprise transmission time delays, and determining whether the N devices and the switches connected to the N devices fail according to the N(N-1) transmission parameters comprises:

[0009] In the N(N-1) transmission time delays, two or more devices corresponding to transmission time delays greater than a first preset time delay are determined;

[0010] If transmission time delays corresponding to a certain device in the two or more devices exceed a first preset proportion of the first preset time delay, the device is marked as a suspicious device;

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

[0012] Whether the suspicious devices fail and whether the suspicious switches fail are determined according to the suspicious devices and the suspicious switches.

[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 time delays corresponding to the third traffic data comprises:

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

[0015] In an exemplary embodiment of the present disclosure, the transmission parameter includes a sending duration for sending the first traffic data, the first traffic data is greater than a second preset data amount, the second preset data amount is greater than the first preset data amount, and determining whether the congestion control capability of the network under test is qualified according to the N(N-1) transmission parameters and the M small flow delays corresponding to the third traffic data includes:

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

[0017] In an exemplary embodiment of the present disclosure, determining whether the congestion control capability of the network under test 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 there is at least one small flow delay greater than a third preset delay in the M small flow delays, it is determined that the congestion control capability of the network under test is unqualified.

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

[0020] In response to the switch accessing the network under test message, determining an identifier of the switch;

[0021] If the identifier of the switch corresponds to the identifier of the malfunctioning switch, controlling the M devices without malfunction in the network under test to send the first traffic data to each other with the device connected to the malfunctioning switch to obtain a plurality of transmission parameters;

[0022] If it is determined that the malfunctioning switch is normal according to the plurality of transmission parameters, marking the malfunctioning switch as a switch without malfunction, marking the device connected to the malfunctioning switch as a device without malfunction, and updating the number M of devices without malfunction.

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

[0024] In response to the device accessing the network under test message, determining an identifier of the device;

[0025] if the identifier of the device corresponds to the identifier of the faulty device, controlling the M devices in the network under test to transmit the first traffic data to each other with the faulty device to obtain the transmission parameter corresponding to the faulty device;

[0026] if it is judged that the faulty device is normal according to the transmission parameter corresponding to the faulty device, marking the faulty device as a device without fault, and updating the number M of devices without fault.

[0027] According to a second aspect of the embodiments of the present disclosure, an electronic device is provided, comprising a memory and a processor coupled to the memory, the processor is configured to execute the method according to any one of the preceding method embodiments based on instructions stored in the memory.

[0028] According to a third aspect of the embodiments of the present disclosure, a computer readable storage medium is provided, and the computer readable storage medium stores a program, the program is executed by a processor to implement the congestion control capability testing method according to any one of the preceding method embodiments.

[0029] According to a fourth aspect of the embodiments of the present disclosure, a computer program product is provided, and the computer program product comprises a computer program, the computer program is executed by a processor to implement the steps of the method according to any one of the preceding method embodiments.

[0030] The embodiments of the present disclosure can quickly identify the unqualified congestion control capability phenomenon without accessing the switch, and further improve the testing efficiency of the congestion control capability, by first controlling the devices in the network under test to perform point-to-point testing to exclude device faults and switch faults, and evaluating the basic state of the network to preliminarily judge the obvious unqualified congestion control capability phenomenon. In addition, by performing the delay test on the devices without fault in the multi-punch congestion scenario, the congestion control capability of the network under test is accurately determined, the queue processing capability of the switch can be measured without accessing the switch, and the testing of the congestion control capability can be accurately implemented without accessing the switch.

[0031] It should be understood that the foregoing general description and the following detailed description are only exemplary and explanatory, and cannot limit the present disclosure. BRIEF DESCRIPTION OF DRAWINGS

[0032] The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate embodiments consistent with the present disclosure and serve to explain the principles of the present disclosure. It is apparent that the accompanying drawings in the following description are only some embodiments of the present disclosure, and other drawings can be obtained by those skilled in the art without creative labor based on these drawings.

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

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

[0035] Figure 3 is a sub-flow chart of step S3 in the exemplary embodiments of the present disclosure.

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

[0037] Figure 5 is a flow chart of updating the number of devices after step S3 in the exemplary embodiments of the present disclosure.

[0038] Figure 6 is a schematic diagram of performing a small flow latency test in the exemplary embodiments of the present disclosure.

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

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

[0041] Example implementations will now be described more fully with reference to the accompanying drawings. Example implementations can be implemented in any

[0042] In addition, the accompanying drawings are included to provide a further understanding of the present disclosure and are incorporated in and constitute a part of this specification, illustrate embodiments of the present disclosure and together with the description serve to explain the principles of the present disclosure. In the drawings:

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

[0044] Figure 1 is a flowchart of a congestion control capability test method in the example embodiments of the present disclosure.

[0045] Reference Figure 1 The congestion control capability test method 100 can include:

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

[0047] Step S2, controlling the ith device to send first traffic data to the jth device to obtain an ijth transmission parameter, and controlling the jth device to send the first traffic data to the ith device to obtain a jith 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 switch to which the N devices are connected fail according to the N(N-1) transmission parameters, marking the switch and the device that fail as a faulty switch and a faulty device respectively, and marking the devices connected to the faulty switch as faulty devices;

[0049] Step S4, in M devices among the N devices excluding the faulty devices, controlling M-2 devices to send second traffic data to the kth device, and one device to send the second traffic data and third traffic data to the kth device to obtain a kth small flow time delay corresponding to the third traffic data, the third traffic data being less than a first preset data amount, 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 time delays corresponding to the third traffic data.

[0051] The example embodiments of the present disclosure can quickly identify the unqualified congestion control capability phenomenon without accessing the switch, thereby improving the test efficiency of the congestion control capability, by first controlling the devices in the network to be tested to perform point-to-point testing to exclude device failures and switch failures and evaluate the basic state of the network to preliminarily judge the unqualified congestion control capability phenomenon. In addition, the example embodiments of the present disclosure can accurately determine whether the congestion control capability of the network to be tested is qualified by performing time delay testing on the devices without failure in a multi-punch congestion scenario, thereby measuring the queue processing capability of the switch without accessing the switch and accurately performing the test of the congestion control capability without accessing the switch.

[0052] The following describes each step of the congestion control capability test method 100 in detail.

[0053] At step S1, N devices in the network under test are determined, which are connected to at least one switch.

[0054] Figure 2 FIG. 1 is a schematic diagram of a network under test in an example embodiment of the present disclosure.

[0055] Reference is made to Figure 2 The network under test 200 can include at least one switch 21, each switch 21 is connected to at least one device 22, the number of devices in the network under test 200 is N, N≥1. The devices 22 can be various computing nodes, storage devices, and network attached devices, and the devices 22 can communicate through the switches 21. The switches 21 are connected (directly or through upper-layer switches such as core switches).

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

[0057] When the network under test 200 is an RDMA network, the switches 21 can recognize and process RDMA packets and quickly forward the packets to the devices 22 according to the network topology and traffic load. The devices 22 connected to each switch 21 can be servers with strong computing power, which are equipped with high-performance processors and large-capacity memories and are specially used for processing complex computing tasks; or can be mass storage devices such as disk arrays, etc., which are used for storing massive data resources.

[0058] Due to the stringent requirements of the RDMA network on performance and stability, the switches 21 and the devices 22 need to be configured with a congestion control algorithm to ensure the data transmission performance of the entire network. The congestion control algorithm is a key mechanism designed to prevent the network from performance degradation or even collapse due to excessive data traffic.

[0059] At the switch 21 level, its congestion control algorithm monitors the traffic load of each port. For example, it counts the number of data packets received by the port per unit of time, the byte traffic, and the queue length, etc. When it finds that the traffic of a certain port is close to or exceeds its carrying capacity, it starts congestion control, such as prioritizing the data packets entering the port, ensuring that high-priority RDMA traffic (such as data transmission related to real-time computing tasks) can pass first, while appropriately delaying or throttling low-priority traffic (such as some background data synchronization tasks). At the same time, the congestion control algorithm of the switch 21 can also interact with adjacent switches to coordinate the adjustment of the traffic path and direct part of the traffic to the lightly loaded links to balance the load of the entire network.

[0060] At the device 22 level, its congestion control algorithm mainly focuses on its own sending and receiving buffer management and response to network congestion signals. On the sending side, the device 22 dynamically adjusts the sending rate according to the occupancy of its own buffer and the congestion feedback received from the network (such as the congestion notification sent by the switch 21 or the indirect perception of congestion by detecting the change of data packet delay). When the buffer is about to be filled or there are signs of network congestion, the device 22 reduces the sending rate to avoid further exacerbating network congestion. On the receiving side, the 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, the device 22 can temporarily apply for more memory space or preprocess the data to speed up the transfer of data from the buffer.

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

[0062] Therefore, with the update of the congestion control algorithm, it is necessary to test the congestion control capability of the congestion control algorithm configured by the network under test 200 to ensure that the congestion control algorithm can meet the business requirements.

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

[0064] In the example embodiment, the test method of the embodiment of the present disclosure can be implemented by one of the N devices 22 or by a special test device connected to each switch 21. Regardless of the implementation, the tester can input the test configuration information of the device executing the method 100 before the test, which includes, for example, the IP address of the management port of each device 22, the IP address of the RDMA port, and the test result saving path. Since the method of the embodiment of the present disclosure is implemented without accessing the switch, as long as the communication connection between the device executing the method 100 and each switch 21 is normal, the switch 21 does not need to be set.

[0065] In addition, the type of the traffic data (for example, write, send, and read types) sent by the device 22, the data amount (for example, the number of bytes (Byte) or bits (bit)), the transmission protocol (TCP, UDP, and the like), and other related parameters (such as the packet size) need to be set.

[0066] In the embodiment of the present disclosure, the test is performed by controlling the transmission of the fixed data amount of the traffic data between the devices 22. In the same kind of test, the data amount of the traffic data transmitted between the devices 22 is the same. Therefore, the data amount of the corresponding traffic data can be set in advance according to the test type.

[0067] In the example embodiment, the same kind of test can be set multiple times, and each test corresponds to one type of traffic. For example, when performing the transmission delay test, the transmission delay of the first traffic data of the write type, the transmission delay of the first traffic data of the send type, and the transmission delay of the first traffic data of the read type sent between the devices 22 can be tested three times. For this purpose, three kinds of first traffic data can be set, and each kind of first traffic data corresponds to one type of traffic. Since the comparison of the transmission delay is between the same kind of traffic, the data amount of the first traffic data of different traffic types can be the same or different, which will be described in detail in the subsequent embodiments.

[0068] Finally, the serial numbers of the devices 22 can also be set, so as to realize subsequent test control. For example, identifiers of N devices 22 are written into a list or an array, and the identifiers are sorted according to certain rules, which can be based on physical positions, performance parameters, or hierarchical relationships in a network topology of the devices.

[0069] When sorting based on physical positions, if the devices are distributed according to positions of cabinets and racks in a computer room, the devices can be sequentially assigned serial numbers in the 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 regions can be conveniently selected for targeted testing, and local network problems such as communication abnormalities between devices in a certain cabinet can be quickly located.

[0070] In addition, the devices can also be sorted according to performance parameters, with devices having high processing capabilities, large memories, and high network interface rates being placed in front, and devices having relatively weak performance being placed in back. When simulating congestion scenarios, the collaborative working conditions between high-performance devices and low-performance devices, and whether the allocation of network resources between devices of different performance is reasonable can be clearly observed according to test data.

[0071] When sorting according to hierarchical relationships in a network topology, it is suitable for complex network architectures, such as division of devices in core layers, aggregation layers, and access layers. Core layer devices are placed at the front end of the list, aggregation layer devices are placed next, and access layer devices are placed last. In this way, when testing the hierarchical architecture performance, data flow direction, and interaction between different hierarchical layers of a network, the testing can be performed in an orderly manner.

[0072] When the serial numbers of the devices are determined and recorded in a list or an array, during test control, specific devices can be quickly located according to the serial numbers, and operations such as individual parameter configuration, flow sending and receiving control, and state monitoring can be performed on the devices. For example, when performing multi-device concurrent flow testing, the flow testing processes of the devices can be sequentially started according to the serial numbers, to ensure the orderliness and accuracy of the testing. Or when a fault occurs in a certain region of a network, the faulty device and the devices connected to the faulty device can be quickly located according to the serial numbers of the devices, to improve the efficiency of fault diagnosis and repair, and to ensure efficient and stable advancement of the entire network testing work, thereby providing a solid foundation for network performance evaluation and optimization in complex network environments such as intelligent computing centers and storage centers.

[0073] After the related test setting configurations of the devices 22 participating in the testing are determined, the point-to-point testing can be started in step S2.

[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 refers to performing point-to-point unidirectional communication between N devices in a test type to obtain transmission parameters corresponding to N(N-1) point-to-point communications.

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

[0077] For example, when testing 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, communicate between two devices, and record the ijth transmission delay as the difference between the receiving time and the sending time of the first traffic data sent by the i-th device to the j-th device, and record the jith transmission delay as the difference between the receiving time and the sending time of the first traffic data sent by the j-th device to the i-th device. Then, switch to the next group of devices for testing until the pairwise testing of N devices is completed, and obtain N (N-1) transmission delays corresponding to the read type traffic.

[0078] Next, you can change the first traffic data to the write type and re-test the devices to obtain N(N-1) transmission delays corresponding to the write type traffic. And so on. Depending on the test requirements, you can also adjust other elements of the first traffic data (traffic type is only an example) to measure the transmission delay corresponding to each combination of elements.

[0079] Transmission latency can reflect the current network's basic operating status. If some transmission delays are excessive, it indicates an issue with at least one of the devices, switches, or congestion control algorithms. Detailed judgment logic is described below.

[0080] In an exemplary embodiment, the transmission parameters include the duration for a device to complete sending the first traffic data. In this case, the data volume of the first traffic data needs to be fixed and large, for example, larger than a second preset data volume, to facilitate measuring the duration of sending the first traffic data. The transmission duration is used to determine the network bandwidth of the network under test under the current congestion control algorithm. The congestion control algorithm adjusts the traffic transmission rate of each device based on the network bandwidth.

[0081] In the embodiments of the present disclosure, the sending duration of the first traffic data with a fixed data volume sent by the device test can reflect the sending rate of the device, so as to determine whether the congestion control algorithm automatically adjusts the sending rate, and to determine whether the congestion control algorithm has an impact on the network bandwidth. Since the test is performed through one-way communication between each pair of devices, if the data volume of the first traffic 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 the sending duration of a certain device exceeds the first preset duration, 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 be performed for different traffic types, such as the read type traffic and the write type traffic described above. Details are not repeated here.

[0083] It should be noted that the environment of the network to be tested should be stable during the test, and other external interference factors should be excluded, such as other irrelevant traffic bursts, other device network resource occupation, and potential influences in complex network topologies, and it is ensured that each device does not run other relatively complex tasks (for example, the total CPU or memory occupation rate is more than 10%), so as to avoid interference of other factors with the test result judgment.

[0084] The transmission delay test and the network bandwidth (sending duration) test described above can be implemented only one of them, or simultaneously (measuring the sending duration and the transmission delay of the first traffic data at the same time), or sequentially (for example, testing the transmission delay first, and then testing the sending duration). In the embodiments of the present disclosure, the transmission delay test and the sending duration test are performed sequentially, and the test accuracy is higher.

[0085] In the transmission delay test and the sending duration test described above, since only one device sends one-way traffic and one device receives traffic each time, the basic parameters of the network under the conditions of less transmission tasks, less concurrent connections, and less data packet transmission frequency, etc. can be tested.

[0086] When the devices communicate with each other, the network is relatively idle, that is, the transmission task is small, and the number of concurrent connections is small. In this case, 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 the number of channels for data interaction at the same time is limited. At this time, if an exception occurs, it is easier to locate the problem of a specific device or connection link. Since the data packets are transmitted between two devices, the frequency of data packet transmission is small, which can reduce mutual interference during data transmission, making the transmission of a single data packet more easily observed and analyzed, such as whether the transmission delay is stable. These transmission parameters are very important for determining whether the device is working normally and whether the congestion control is abnormal. 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 the transmission parameters such as transmission delay or transmission time are problematic, in the absence of a complex network environment to mislead and mislead, there is a high probability that one of the three reasons for device failure, switch failure, and unqualified congestion control capability. The setting of step S2 can quickly locate the fault, discover the fault as soon as possible, and improve the 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 less transmission task, less number of concurrent connections, and less frequency of data packet transmission. To determine device failure and intuitively and quickly detect congestion control capability abnormalities. Those skilled in the art can set the types and number of transmission parameters according to the test requirements, and the present disclosure is not limited thereto.

[0089] After measuring the transmission parameters, the transmission parameters can be used to first screen the faults to quickly discover obvious problems and improve test efficiency.

[0090] In step S3, whether the N devices and the switches connected by the N devices have a fault is determined according to the N(N-1) transmission parameters, and the switches and devices that have a fault are marked as fault switches and fault devices, respectively. The devices connected by the fault switches are marked as fault devices.

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

[0092] Reference Figure 3 In the exemplary embodiment, step S3 can include:

[0093] In step S31, among the N(N-1) transmission delays, two or more devices corresponding to the transmission delays greater than the first preset delay are determined.

[0094] Step S32, if the transmission delay corresponding to a device of the two or more devices exceeds the first preset proportion of the first preset delay, mark the device as a suspicious device;

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

[0096] Step S34, determine whether the suspicious device is faulty and whether the suspicious switch is faulty according to the suspicious device and the suspicious switch.

[0097] As analyzed above, in a network environment with less transmission tasks, less concurrent connections, and less data packet transmission frequency, if the transmission delay is large, it is likely that at least one of the three problems of device failure, switch failure, and unqualified congestion control capability exists. Therefore, the first preset delay is set to filter the transmission delays with problems.

[0098] The first preset delay can be determined according to the environment of the network to be tested, the types and performance of the devices, the data volume of the first traffic data, and other reference factors. For example, a reasonable transmission delay can be determined according to the measured results, which need to be obtained in a network environment with no device failure and unqualified congestion control capability, and the transmission delay corresponding to an abnormal situation is determined on this basis, so that the first preset delay is reasonably determined.

[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 it sends or receives (because some devices may have normal sending function and abnormal receiving function, etc.). The reason for marking as a suspicious device rather than a faulty device is that some transmission abnormalities may be caused by switch failure or unqualified congestion control capability, so only suspicious devices are marked in step S31.

[0100] Next, in step S32, the transmission delays corresponding to each suspicious device (as a receiving party and as a sending party) 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 is likely that the device has an abnormality. The first preset proportion can be set to be relatively high, for example, 80%, to improve the accuracy of judgment.

[0101] If most of the transmission delays corresponding to a suspicious device do not exceed the first preset delay, further investigation of other reasons can be continued.

[0102] In step S33, in the process of determining the switch failure, the devices connected to the switch are also first summarized, and the proportion of abnormal devices is determined. If more than a second preset proportion of the 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 switch and the suspicious device.

[0104] In some embodiments, the method for determining the faulty device and the faulty switch based on the suspicious device and the suspicious switch, for example, for the suspicious device, temporarily interrupts its connection with other devices, uses a backup link (if available) or is directly connected to a known normal switch port, restarts the flow test with other normal devices, and observes whether the 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 the failure is probably a problem with the hardware or software configuration of the device itself, such as a network card failure, an abnormal driver, etc.

[0105] For the suspicious switch, select some devices connected to its port, transfer the connection of these devices to another normally operating switch (provided that there is a backup switch available for deployment), and perform the flow test again to compare the transmission delay changes of these devices before and after the transfer. If the delay is significantly improved after the transfer and approaches or reaches the expected value in the normal network environment, it can be determined that the switch has a fault, and the fault point may be in the switch matrix, port module, or congestion control module inside the switch.

[0106] In addition, clustering analysis techniques can also be introduced to assist in judgment. The relevant parameters of all devices and switches, such as the average transmission delay, the standard deviation of the transmission delay, the flow rate, the number of connected devices, etc., are used as feature vectors, and a clustering algorithm (such as the K-Means algorithm) is used for clustering. Normal devices and switches will usually be clustered in one or a few 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 device and the faulty switch can be further confirmed. For example, if other devices in the cluster where a suspicious device is located also exhibit similar problems such as high latency, low flow rate (high transmission time), and the cluster is clearly distinguished from the normal cluster, the likelihood of the device being faulty is higher. Similarly, for a suspicious switch, if most of the devices connected to it are located in a problem cluster, it can also provide strong evidence for determining its failure.

[0107] During the entire troubleshooting process, various types of test data can be automatically recorded and automatically output (for example, through a txt document or output to the screen), including the detailed results of each flow test, configuration changes of the devices and switches, etc., to facilitate subsequent review and analysis, continuously optimize fault judgment methods, improve the efficiency and accuracy of network operation, and ensure that the network under test operates 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, the faulty device or the faulty switch can be directly cut out of the network under test, and the next test can be performed based only on the remaining M devices and switches that can ensure normal operation. Alternatively, the faulty device or the faulty switch can be repaired and reconnected to the network under test after a period of time.

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

[0110] Reference Figure 4 The process of updating the number of devices can include:

[0111] Step S301, in response to the message of the switch accessing the network under test, determining the identifier of the switch;

[0112] Step S302, if the identifier of the switch corresponds to the identifier of the faulty switch, controlling the M devices without faults in the network under test and the devices connected to the faulty switch to transmit first traffic data to each other to obtain a plurality of transmission parameters;

[0113] Step S303, if it is determined that the faulty switch has returned to normal according to the plurality of transmission parameters, marking the faulty switch as a normal switch and marking the devices connected to the faulty switch as normal devices, and updating the number M of normal devices.

[0114] Figure 4 In the example embodiment shown, if the faulty switch is repaired and reconnected to the network under test, the identifier of the switch can be used to determine that it is a repaired faulty switch, and then a detection program is started to control the devices connected to the switch to perform pairwise tests with other normal devices in the network under test, such as step S2, to determine whether the transmission delay of the devices connected to the switch has returned to normal, for example, the transmission delay of the devices is less than the first preset delay to determine that the devices have returned to normal and the switch has returned to normal. Then, the marking state of the switch and the devices connected to it is updated, and the number M of normal devices is updated.

[0115] Figure 5 FIG. 3 is a flowchart of updating the number of devices after step S3 in the example 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 indicating that the device has accessed the network to be tested, and determining the identifier of the device;

[0118] Step S305: If the device identifier corresponds to the identifier of the faulty device, control M healthy devices in the network under test to send first traffic 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 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.

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

[0121] By identifying faulty devices and switches based on transmission parameters and updating device records after repair, abnormal test results caused by device and switch failures can be eliminated in a simple test environment, and subsequent tests can be performed in a normal device environment, improving test efficiency and 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 traffic data to the kth device, and one device sends the second traffic data and the third traffic data to the kth device to obtain the kth small flow delay corresponding to the third traffic data, and the third traffic 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 flow (a data flow with small data packets and short duration) refers to a data flow with relatively small data volume and specific traffic characteristics in network data transmission. When a large number of large flows are transmitted in the network, the cache space and bandwidth resources of the network device can be occupied, causing the small flow to face the situation of queuing and delayed processing in the transmission process. Therefore, when the small flow passes through the switch queue, the delay of the small flow 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 in 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 the scenario of actively causing congestion (controlling multiple devices to flow to one device) in step S4, the delay data of the small flow superimposed in the flow traffic can reflect the length of the current switch queue when the network under test is in the network congestion state, thereby evaluating the congestion control capability of the algorithm. At the same time, the switch is avoided to greatly simplify the deployment difficulty.

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

[0127] Reference Figure 6 It is assumed that there are two switches 211 and 212 in the network under test 200, and each switch is connected to three devices, a total of six devices 221-226. The six devices and the two switches are all fault-free, and M = 6.

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

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

[0130] Similarly, six small flow time delays are measured. Since the six devices are connected to the two switches respectively, the six tests and six small flow time delays can reflect the queue length of the two switches in multiple directions, and comprehensively test the queue length of the switches.

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

[0132] In step S5, 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 time delays corresponding to the third traffic data.

[0133] In the exemplary embodiment, if there is a transmission time delay greater than the second preset time delay in the N(N-1) transmission time 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 time delay is set to screen the devices and switches with problems in sending and receiving mechanisms. The first preset time delay can be calculated or measured, and corresponds to scenarios such as device failure and switch failure.

[0135] In the present embodiment, the second preset time delay is set to identify the unqualified problem of the congestion control capability. Compared with the first preset time delay, the second preset time delay can be set relatively loose. Because the first preset time delay mainly focuses on the case that the transmission time delay of the device and the switch is abnormally increased due to local faults of the hardware or software in the normal operation state, and the purpose is to accurately locate the device individual or switch port that may appear fault. The second preset time delay is from the perspective of the congestion control of the whole network, and considers that a certain degree of load fluctuation and reasonable time delay range are allowed in the normal operation of the network. When the transmission time delay exceeds the second preset time delay, it means that the network is in a more serious congestion state and the congestion control mechanism fails to effectively intervene and adjust, resulting in a serious decline in the overall network performance and failing to meet the basic quality of service requirements.

[0136] The determination of the second preset time delay needs to consider multiple factors. On one hand, the design specification and expected service level of the network under test need to be considered. For example, if the network under test is designed to support real-time financial transaction systems that are extremely sensitive to time delay, the second preset time delay must be set very low to ensure that network congestion does not have a substantial impact on the rapid execution of transactions under any circumstances; if it is a general enterprise office network, the tolerance for time delay is relatively high, and the second preset time delay can be appropriately relaxed. On the other hand, historical performance data of the network need to be analyzed. By monitoring the transmission time delay of the network under different load conditions for a long time, a reasonable threshold can be determined using statistical analysis methods, so that under normal business peak conditions and the like, as long as the congestion control mechanism is functioning properly, the transmission time delay will not easily exceed the threshold.

[0137] By quickly screening the unqualified congestion control capability through the second preset time delay, the problem positioning efficiency can be improved - if the transmission time delay is used to determine the unqualified congestion control capability, no subsequent processing and testing is needed.

[0138] Of course, even if the transmission time delay does not exceed the second preset time delay, it does not mean that the congestion control capability is necessarily problem-free, and further judgment needs to be made in combination with other transmission parameters.

[0139] In an exemplary embodiment, if there is at least one sending time length greater than the first preset time length among the N(N-1) sending time lengths, it is determined that the congestion control capability of the network under test is unqualified.

[0140] As analyzed above, in a point-to-point test, the data amount of the first transmission flow is controlled, and network congestion does not occur. Therefore, the sending time length of each device for the first transmission flow should be relatively close. If the measured sending time length is greater than the first preset time length, and after excluding device failure, it is determined that the congestion control mechanism has a problem, and the congestion control capability is unqualified, and the current congestion control algorithm needs to be modified.

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

[0142] According to the analysis above, when a small flow (which can be understood as a data flow with small data packets and 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 switch queue length increases, the waiting time of the small flow after entering the queue will become longer, which will lead to an increase in the small flow delay. Therefore, the switch queue length can be indirectly reflected by monitoring the small flow delay. The small flow delay reflects the switch queue length. If the delay of any small flow 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 elaborated here.

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

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

[0145] In step S72, a point-to-point bandwidth test is performed to determine the transmission time of the device sending a fixed amount of traffic data. In the point-to-point test, two loops are required: an outer loop and an inner loop. The outer loop includes recording the number of outer loops i and starting the server i (i.e., the i-th device) required for the test; the inner loop includes recording the number of inner loops j, starting the server j (i.e., the j-th device) required for the test, 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 device i is entered; in the inner loop, the other N-1 devices are selected respectively to communicate with device i, and each device communicates with device i twice. The corresponding transmission parameters are recorded and output for each communication. After all N-1 devices have completed communication, the current inner loop ends, returns to the outer loop, selects device i+1, and enters the inner loop corresponding to device i+1, achieving 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 here.

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

[0148] Step S741, start multi-shot incast background traffic, that is, control M-1 devices to send second traffic data to one device at the same time. The incast traffic is a special traffic mode, which usually occurs in scenarios such as data center networks. When multiple senders simultaneously send incast traffic to one receiver, 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 third traffic data in the second traffic data, and the third traffic 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, which RDMA operation (send, read, write, etc.), the number of QPs (Queue Pairs), and the traffic direction used in each test are all configurable by the operation and maintenance personnel. Among them, the QP is the basic unit of communication under the architecture of RDMA, which is composed of a sending queue and a receiving queue, and is used to realize efficient transmission of data 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 realized through virtual modules such as an automatic test module, a test result acquisition module, and a result output module, and the present disclosure does not make special limitations thereto.

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

[0155] In summary, the embodiments of the present disclosure can implement a congestion control evaluation scheme in a physical environment without the need for switch login information (the existing scheme needs to be configured with switch login information, logged into the switch and data collection through the SNMP protocol, and since the end-side network card operation and maintenance personnel usually have difficulty obtaining switch login permissions, this scheme is difficult to deploy in practice). By using the small flow delay in the congestion scenario to indirectly perceive the switch queuing state, pure end-side deployment of the congestion control capability test can be implemented, and the implementability is strong. In addition, by setting up an automatic evaluation of the point-to-point basic capabilities in the network to be tested, it is convenient to quickly find and locate problem nodes. At the same time, the congestion control capabilities of the congestion control algorithm for different communication primitives (traffic types) and different message lengths (data amounts) are comprehensively evaluated. Finally, the operation and maintenance personnel only need to simply configure the end-side related configuration information to obtain a complete test report, which can greatly improve the efficiency and accuracy of evaluation and verification.

[0156] Therefore, the embodiments of the present disclosure can efficiently and accurately evaluate the congestion control capabilities of the congestion control algorithm currently used in the network to be tested by simple settings, tests and judgments without logging into the switch, only relying on the terminal device.

[0157] It should be noted that although several modules or units of the device for action execution are mentioned in the foregoing detailed description, such 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. Conversely, the features and functions of one module or unit described above can be further divided into a plurality of modules or units.

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

[0159] Those skilled in the art can understand that each aspect of the present disclosure can be implemented as a system, a method or a program product. Therefore, each aspect of the present disclosure can be embodied as a complete hardware embodiment, a complete software embodiment (including firmware, microcode, etc.), or an embodiment combining software and hardware aspects, which can be collectively referred to as "circuitry", "module" or "system" here.

[0160] The electronic device 800 according to this embodiment of the present disclosure will be described below with reference to Figure 8 Figure 8 ​The electronic device 800 shown is merely one example and should not be taken as limiting the scope of the present embodiments. The electronic device 800 can be any of the devices 22 in the network 200 under test, or can be a special-purpose test device that is separate from the devices 22. The electronic device 800 is configured to perform the methods described above.

[0161] As shown in Figure 8 The electronic device 800 is in the form of a general computing device. Components of the electronic device 800 can include, but are not limited to, the at least one processing unit 810, the at least one storage unit 820, and a bus 830 that connects the various system components, including the storage unit 820 and the processing unit 810.

[0162] The storage unit stores program code that can be executed by the processing unit 810 such that the processing unit 810 performs the steps described above in the "Exemplary Methods" section of this specification according to various exemplary embodiments of the present application. For example, the processing unit 810 can perform the methods as shown in the embodiments of the present disclosure.

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

[0164] The storage unit 820 can further include program / utility 8204 having a set of programs / modules 8205, including operating system, one or more applications, other program modules, and program data, each or some combination thereof, which can include implementation of a network environment.

[0165] The bus 830 can represent one or more of several types of bus structures, including a storage bus or bus controller, a peripheral bus, a graphics acceleration port, a processor or local bus using any of a variety of bus structures, and the like.

[0166] The electronic device 800 can also communicate with one or more external devices 900 (e.g., a keyboard, a pointing device, a Bluetooth device, etc.), one or more devices that enable a user to interact with the electronic device 800, and / or any device that enables the electronic device 800 to communicate with one or more other computing devices (e.g., a router, a modem, etc.). Such communication can occur via an input / output (I / O) interface 850. Furthermore, the electronic device 800 can also communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN), and / or a public network 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 can 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.

[0167] Through the description of the above embodiments, it is easy for those skilled in the art to understand that the example embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solution according to the embodiments 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, and includes 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 embodiments of the present disclosure.

[0168] In exemplary embodiments of the present disclosure, a computer-readable storage medium is also provided, on which is stored a program product capable of implementing the aforementioned methods of this specification. In some possible implementations, various aspects of the present invention may also be implemented in the form of a program product comprising program code. When the program product is executed on a terminal device, the program code is configured to cause the terminal device to execute the steps according to various exemplary embodiments of the present invention described in the "Exemplary Methods" section of this specification.

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

[0170] The program product can employ any combination of one or more computer-readable media. The computer-readable media can be a computer-readable storage medium or a computer-readable signal medium. The computer-readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer-readable storage medium include the following: an electrical connection having one or more wires, a portable disc, 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 disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0171] The computer-readable signal medium can include a computer-readable storage medium that is propagated as a carrier wave. The computer-readable signal medium can further be any computer-readable medium that is not a storage medium. The computer-readable signal medium can be a computer-readable storage medium that is a propagated signal on a computer-readable storage medium.

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

[0173] The program code can be executed by one or more programmable processors, which can be implemented in one or more computer systems. In this context, a computer system generally includes a plurality of these programmable processors, which work in concert to perform a task. Additionally, the program code can be downloaded from an external source, including the internet, through a computer network, or through a broadcast medium.

[0174] Furthermore, the above-described diagrams are merely schematic illustrations of the processes included in the method according to the exemplary embodiments of the present application, and are not intended to be limiting. It is readily understood that the processes shown in the above-described diagrams do not indicate or limit the time sequence of the processes. In addition, it is readily understood that the processes can be executed synchronously or asynchronously, for example, in a plurality of modules.

[0175] Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the features disclosed herein. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

Claims

1. A method of testing congestion control capabilities, characterized by, The method comprises the following steps: determining N devices in a network to be tested, the N devices being connected to at least one switch; controlling the ith device to send first traffic data to the jth device to obtain an ijth transmission parameter, and controlling the jth device to send the first traffic data to the ith device to obtain a jith 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, marking the faulty switches and devices as faulty switches and devices respectively, and marking the devices connected to the faulty switches as faulty devices; in M devices among the N devices excluding the faulty devices, controlling M-2 devices to send second traffic data to the kth device, and one device to send the second traffic data and third traffic data to the kth device to obtain a kth small flow time delay corresponding to the third traffic data, the third traffic data being smaller than a first preset data amount, 2≤M≤N, 1≤k≤M; 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 time delays corresponding to the third traffic data.

2. The congestion control capability testing method of claim 1, wherein, The transmission parameters comprise transmission time delays, and determining whether the N devices and the switches connected to the N devices are faulty according to the N(N-1) transmission parameters comprises the following steps: in the N(N-1) transmission time delays, determining two or more devices corresponding to transmission time delays greater than a first preset time delay; if the transmission time delay of a certain device in the two or more devices exceeds the first preset proportion of transmission time delays greater than the first preset time delay, marking the device as a suspicious device; if the proportion of suspicious devices in the devices connected to a switch is greater than a second preset proportion, marking the switch as a suspicious switch; determining whether the suspicious devices are faulty and whether the suspicious switches are faulty according to the suspicious devices and the suspicious switches.

3. The congestion control capability testing method of claim 2, wherein, 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 time delays corresponding to the third traffic data comprises the following steps: if there is a transmission time delay greater than a second preset time delay in the N(N-1) transmission time delays, determining that the congestion control capability of the network to be tested is unqualified.

4. The congestion control capability testing method of claim 1, wherein, The transmission parameters comprise transmission time lengths for completing the sending of the first traffic data, the first traffic data being greater than a second preset data amount, the second preset data amount being greater than the first preset data amount, 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 time delays corresponding to the third traffic data comprises the following steps: if at least one transmission time length in the N(N-1) transmission time lengths is greater than a first preset time length, determining that the congestion control capability of the network to be tested is unqualified.

5. The congestion control capability testing method of claim 1, wherein, 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 time delays corresponding to the third traffic data comprises the following steps: If there is at least one of the M stream latencies greater than a third preset latency, it is determined that the congestion control capability of the network under test is unqualified.

6. The congestion control capability testing method of claim 1, wherein, After the malfunctioning switch is marked as a faulty switch, the device connected to the faulty switch is marked as a faulty device, and the malfunctioning device is marked as a faulty device, the method further comprises: In response to the switch accessing the network under test message, determining the identifier of the switch; If the identifier of the switch corresponds to the identifier of the faulty switch, controlling the M devices without malfunction in the network under test to send the first traffic data to each other with the device connected to the faulty switch to obtain a plurality of transmission parameters; If it is determined that the faulty switch is normal according to the plurality of transmission parameters, marking the faulty switch as a non-faulty switch, marking the device connected to the faulty switch as a non-faulty device, and updating the number M of non-faulty devices.

7. The congestion control capability testing method of claim 1 or 6, wherein, After the malfunctioning switch is marked as a faulty switch, the device connected to the faulty switch is marked as a faulty device, and the malfunctioning device is marked as a faulty device, the method further comprises: In response to the device accessing the network under test message, determining the identifier of the device; If the identifier of the device corresponds to the identifier of the faulty device, controlling the M devices without malfunction in the network under test to send the first traffic data to each other with the faulty device to obtain the transmission parameter corresponding to the faulty device; If it is determined that the faulty device is normal according to the transmission parameter corresponding to the faulty device, marking the faulty device as a non-faulty device, and updating the number M of non-faulty devices.

8. An electronic device, comprising: Comprise: a memory; and a processor coupled to the memory, the processor configured to perform the method of any one of claims 1-6 based on instructions stored in the memory.

9. A computer readable storage medium having stored thereon a program which, when executed by a processor, implements the method of any one of claims 1-6.

10. A computer program product comprising a computer program, characterized in that, The computer program, when executed by a processor, implements the steps of the method of any one of claims 1-6. The computer program, when executed by a processor, implements the steps of the method of any one of claims 1-6.

Images