Network delay analysis method, apparatus, program product, and electronic device

Abstract

This disclosure provides a network latency analysis method, apparatus, program product, and electronic device, relating to the field of communication technology. The method includes: dividing devices within a cluster into at least one multicast group according to the network topology; sending multicast probe packets to each multicast group via unreliable datagrams; determining the reception information of each device within each multicast group receiving the multicast probe packets; and determining network latency information based on the reception information corresponding to each device within each multicast group. This disclosure determines network latency information using only one-way probe packets, which, while ensuring network latency determination performance, also reduces the consumption of network and computing resources, avoiding latency and packet loss caused by excessive network resource consumption.

Description

Technical Field

[0001] This disclosure relates to the field of communication technology, and in particular to a network latency analysis method, apparatus, program product and electronic device. Background Technology

[0002] Currently, with the rise of cloud computing and big data, the scale of intelligent computing centers providing computing power is rapidly expanding. Specifically, these centers correspond to large-scale distributed systems with tens of thousands of servers and network devices. Identifying network faults among these tens of thousands of servers and network devices within these large-scale distributed systems has become a crucial aspect of improving their performance.

[0003] Among related technologies, Pingmesh, a large-scale system for data center network latency measurement and analysis, analyzes and troubleshoots the network by measuring the round-trip time (RTT) between servers. However, when using Remote Direct Memory Access (RDMA) technology to acquire data to measure server RTT, it is necessary to perform the creation and destruction of queue pairs (QPs) and the management of too many QPs. The aforementioned QP-related processing consumes hardware computing power and affects hardware performance. Summary of the Invention

[0004] This disclosure provides a network latency analysis method, a network latency analysis device, a computer program product, and an electronic device, which, while ensuring the determination of network latency performance, also reduce the consumption of network and computing resources, and avoid latency and packet loss caused by excessive network resource consumption.

[0005] According to a first aspect of this disclosure, a network latency analysis method is provided, the method comprising:

[0006] Based on the network topology, the devices within the cluster are divided into at least one multicast group;

[0007] Multicast probe packets are sent to each of the multicast groups using unreliable datagrams.

[0008] Determine the reception information of each device within each multicast group for receiving the multicast probe packet;

[0009] Network latency information is determined based on the received information of each device within each multicast group.

[0010] In one possible implementation, based on the network topology, the devices within the cluster are divided into at least one multicast group, including:

[0011] Based on network topology and service allocation requirements, the devices within the cluster are divided into at least one multicast group.

[0012] In one possible implementation, network delay information is determined based on the reception time information corresponding to each device within each multicast group, including:

[0013] Based on the received information corresponding to each device in each multicast group, the received summary information corresponding to each device in each multicast group is determined;

[0014] When it is determined that the received summary information corresponding to the first device in the first multicast group meets the preset conditions, point-to-point detection processing is performed on the first device to obtain the detection result information;

[0015] Based on the detection results, the network latency information of the first device is determined.

[0016] In one possible implementation, based on the reception time information corresponding to each device within each multicast group, the summary reception information corresponding to each device within each multicast group is determined, including:

[0017] Based on the received information of each device in each multicast group, determine the packet loss information and / or the time interval information corresponding to the packet loss of each device;

[0018] The packet loss information and / or the time interval information corresponding to the packet loss of each device are used as the summary reception information of each device.

[0019] In one possible implementation, the method further includes:

[0020] If it is determined that the received summary information corresponding to the second device in the first multicast group does not meet the preset conditions, then the network delay information is determined based on the received information corresponding to the second device.

[0021] In one possible implementation, multicast probe packets are sent to each of the multicast groups via unreliable datagrams, including:

[0022] Using unreliable datagrams, multicast probe packets are sent to the corresponding multicast groups according to the multicast time interval; wherein each multicast probe packet contains an incrementing sequence number.

[0023] In one possible implementation, determining the reception information of the multicast probe packets received by each device within each multicast group includes:

[0024] For each of the multicast groups, perform the following operations:

[0025] Determine the number of devices in the multicast group, and based on the number of devices in the multicast group, establish corresponding listening and queue pairs with numbering settings to receive the corresponding multicast probe packets;

[0026] Once it is determined that a device within the multicast group has received the corresponding multicast probe packet, the address information, reception time information, and sequence number of the multicast probe packet are recorded.

[0027] Based on the recorded address information, reception time information, and sequence number of the multicast probe packet sent, the reception information of each device in the multicast group for receiving the multicast probe packet is determined; wherein, each reception information includes sequence number missing information and round-trip time information.

[0028] According to a second aspect of this disclosure, a network latency analysis apparatus is provided, the apparatus comprising:

[0029] A partitioning unit is used to divide devices within a cluster into at least one multicast group based on the network topology.

[0030] The sending unit is configured to send multicast probe packets to each of the multicast groups respectively via unreliable datagrams;

[0031] A determining unit is used to determine the reception information of each device in each multicast group when it receives the multicast probe packet;

[0032] The processing unit is used to determine network delay information based on the received information corresponding to each device in each multicast group.

[0033] In one possible implementation, the partitioning unit is specifically used for:

[0034] Based on network topology and service allocation requirements, the devices within the cluster are divided into at least one multicast group.

[0035] In one possible implementation, the processing unit is specifically used for:

[0036] Based on the received information corresponding to each device in each multicast group, the received summary information corresponding to each device in each multicast group is determined;

[0037] When it is determined that the received summary information corresponding to the first device in the first multicast group meets the preset conditions, point-to-point detection processing is performed on the first device to obtain the detection result information;

[0038] Based on the detection results, the network latency information of the first device is determined.

[0039] In one possible implementation, the processing unit is specifically used for:

[0040] Based on the received information of each device in each multicast group, determine the packet loss information and / or the time interval information corresponding to the packet loss of each device;

[0041] The packet loss information and / or the time interval information corresponding to the packet loss of each device are used as the summary reception information of each device.

[0042] In one possible implementation, the processing unit is specifically used for:

[0043] If it is determined that the received summary information corresponding to the second device in the first multicast group does not meet the preset conditions, then the network delay information is determined based on the received information corresponding to the second device.

[0044] In one possible implementation, the transmitting unit is specifically used for:

[0045] Using unreliable datagrams, multicast probe packets are sent to the corresponding multicast groups according to the multicast time interval; wherein each multicast probe packet contains an incrementing sequence number.

[0046] In one possible implementation, the determining unit is specifically used for:

[0047] For each of the multicast groups, perform the following operations:

[0048] Determine the number of devices in the multicast group, and based on the number of devices in the multicast group, establish corresponding listening and queue pairs with numbering settings to receive the corresponding multicast probe packets;

[0049] Once it is determined that a device within the multicast group has received the corresponding multicast probe packet, the address information, reception time information, and sequence number of the multicast probe packet are recorded.

[0050] Based on the recorded address information, reception time information, and sequence number of the multicast probe packet sent, the reception information of each device in the multicast group for receiving the multicast probe packet is determined; wherein, each reception information includes sequence number missing information and round-trip time information.

[0051] According to a third aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the method of the first aspect described above and possible implementations thereof.

[0052] According to a fourth aspect of this disclosure, an electronic device is provided, comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to perform the method of the first aspect and possible implementations thereof by executing the executable instructions.

[0053] The technical solution disclosed herein has the following beneficial effects:

[0054] In this embodiment, based on the network topology, devices within the cluster are divided into at least one multicast group; multicast probe packets are sent to each multicast group using unreliable datagrams; the reception information of each device within each multicast group is determined; and finally, network latency information is determined based on the reception information of each device within each multicast group. It is evident that this embodiment, by using only one-way probe packets to determine network latency information, not only ensures the performance of determining network latency but also reduces the consumption of network and computing resources, avoiding latency and packet loss caused by excessive network resource consumption.

[0055] Other features and advantages of this disclosure will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the disclosure. The objects and other advantages of this disclosure may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

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

[0057] Figure 1 This illustration shows a schematic diagram of an application scenario in this exemplary embodiment;

[0058] Figure 2 A flowchart illustrating a network latency analysis method in this exemplary embodiment is shown.

[0059] Figure 3 An interactive schematic diagram of a network latency analysis method in this exemplary embodiment is shown;

[0060] Figure 4 This diagram illustrates the structure of a network latency analysis device according to this exemplary embodiment.

[0061] Figure 5 A schematic diagram of the structure of an electronic device in this exemplary embodiment is shown. Detailed Implementation

[0062] To make the objectives, technical solutions, and advantages of this disclosure clearer, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure. Unless otherwise specified, the embodiments and features in the embodiments of this disclosure can be arbitrarily combined with each other. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0063] The term "comprising" and any variations thereof in the specification and claims of this disclosure are intended to cover non-exclusive protection. For example, a process, method, system, product, or apparatus that comprises a series of steps or units is not limited to the steps or units listed, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus.

[0064] In this disclosure, there are one or more embodiments; "multiple" refers to two or more. "And / or" describes the relationship between the associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following associated objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0065] It should be noted that the terms "first," "second," and "third," etc., in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order, sequence, size, or priority. For example, the terms "first service host" and "second service host" in the embodiments of this disclosure are merely used to distinguish different service hosts. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0066] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, which are schematic illustrations of this disclosure and are not necessarily drawn to scale. Some block diagrams shown in the drawings may be functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in hardware modules or integrated circuits, or in networks, processors, or microcontrollers. Implementations can be carried out in various forms and should not be construed as limited to the examples set forth herein. The features, structures, or characteristics described in this disclosure can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough description of embodiments of this disclosure. However, those skilled in the art will recognize that one or more specific details may be omitted when implementing the technical solutions of this disclosure, or other methods, components, apparatuses, steps, etc., may be used to replace one or more specific details.

[0067] It should be noted that certain software, components, models, and other existing industry solutions may be mentioned in the embodiments disclosed herein. These should be considered exemplary and intended only to illustrate the feasibility of implementing the technical solutions disclosed herein, but do not imply that the applicant has already used or necessarily used such solutions. The collection, dissemination, and use of data in the technical solutions disclosed herein all comply with relevant national laws and regulations.

[0068] To better understand the solutions provided in this disclosure, the following is a brief introduction to some key terms used in this disclosure:

[0069] Remote Direct Memory Access (RDMA): A technology that allows network devices to directly read and write to the memory of a remote system without the involvement of a central processing unit (CPU), thereby significantly improving communication efficiency and reducing latency.

[0070] Pingmesh is a large-scale system for measuring and analyzing network latency in data centers. It analyzes and troubleshoots the network by measuring the TCP and HTTP round-trip latency between any two machines in the data center.

[0071] Queue Pair (QP): A virtual interface between hardware and software in RDMA. It is used to store tasks from software to hardware in sequence. These tasks contain information such as data source, length, and destination address.

[0072] Round-Trip Time (RTT): The time elapsed from when the sender starts sending data until the sender receives an acknowledgment from the receiver (the receiver sends an acknowledgment immediately after receiving the data).

[0073] Unreliable Datagram (UD): A transmission mode in RDMA that provides connectionless, unreliable message delivery services.

[0074] Reliable Connection (RC): A transmission mode in RDMA that provides a connection and reliable communication service.

[0075] RDMA over Converged Ethernet (RoCE) is a communication protocol that enables RDMA transmission over Ethernet. RoCEv1 and RoCEv2 are two versions.

[0076] IB (InfiniBand): An RDMA technology based on the InfiniBand architecture, proposed by the IBTA (InfiniBand Trade Association). Building an RDMA network based on IB technology requires dedicated IB network interface cards (NICs) and IB switches.

[0077] GID (Global Identifier): A globally unique identifier in the IB protocol used to identify different nodes in an InfiniBand network to ensure that data is correctly routed to its destination in the network.

[0078] LID (Local Identifier): In the IB protocol, it is used to identify a node within a subnet; it is a local identifier within the subnet. Each node has a unique LID within a subnet, and the LID is used for routing within the subnet.

[0079] Perftest is a toolset for performance testing, specifically designed for benchmarking RDMA and InfiniBand networks.

[0080] Qperf is a tool for testing latency and bandwidth.

[0081] Currently, RDMA communication is limited by hardware resources such as QPs (Queries Per Nodes), and the creation, destruction, and management of too many QPs consume hardware computing power, impacting hardware performance. Unlike TCP or HTTP protocols, it cannot create an arbitrary number of connections at the software level for pingmesh measurements. Furthermore, RDMA requires a lossless network to achieve its high performance. However, in large-scale clusters, end-to-end probing schemes that measure round-trip latency between every two nodes significantly increase network and computational load. Moreover, as the probing scale increases, the consumption of network resources during round-trip experiments can lead to network congestion, further increasing the risk of latency and packet loss. Therefore, a more efficient probing method is urgently needed to alleviate the network burden.

[0082] In view of one or more of the above-mentioned problems, an exemplary embodiment of this disclosure provides a network latency analysis method. This method divides devices within a cluster into at least one multicast group based on the network topology; sends multicast probe packets to each multicast group using unreliable datagrams; determines the reception information of each device within each multicast group that receives the multicast probe packets; and finally determines network latency information based on the reception information corresponding to each device within each multicast group. It is evident that this embodiment of the disclosure reduces the consumption of network and computing resources by using only one-way probe packets to determine reception information, thereby ensuring performance while enabling timely location and troubleshooting of network problems.

[0083] To better understand the technical solutions provided in the embodiments of this disclosure, the following is a brief introduction to the application scenarios applicable to the technical solutions provided in the embodiments of this disclosure. It should be noted that the application scenarios described below are only for illustrating the embodiments of this disclosure and are not intended to limit the scope. In specific implementation, the technical solutions provided in the embodiments of this disclosure can be flexibly applied according to actual needs.

[0084] In this embodiment of the disclosure, network latency analysis technology can be applied to various business scenarios that require connection to cloud computing and large models, such as social marketing, video recommendation, and business processing. This embodiment of the disclosure does not limit this application.

[0085] Please see Figure 1 As shown, Figure 1This is an application scenario to which the technical solution of this disclosure embodiment can be applied. In the schematic diagram of this scenario, a server cluster 100 is included, comprising multiple devices, each of which can be understood as a business host. To perform network latency analysis on the server cluster 100, the multiple devices within the server cluster 100 can be functionally divided into control devices and probe processing devices. The probe processing device can act as both a probe and a probed end, and operates through a simplified daemon process. This daemon process runs on the probe processing device and is primarily responsible for handling communication with the control end and sending and receiving probe packets.

[0086] In this embodiment, the probe terminal functions as follows: after starting the monitoring control terminal message service, it executes a layered probe scheme based on the control terminal messages. The layered probe scheme is as follows: first, it performs UD-based multicast probe; then, when the control terminal analyzes the presence of a potentially abnormal probed terminal, it performs RC-based point-to-point probe on the abnormal probed terminal.

[0087] In this embodiment, the probe end can establish a parent thread to start the probe parameter service of the control end, receive probe information from the control end, and determine whether to execute thread 1 or thread 2. Thread 1 performs UD-based multicast probes. Specifically, it can send multicast probe packets to the multicast group through UD according to the probe interval. Thread 2 performs RC-based point-to-point probes. Specifically, it establishes an RC connection with the abnormal probed end, sends probe messages, and closes the RC connection after sending.

[0088] In this embodiment of the disclosure, the function of the probed end is implemented as follows: after starting the listening probe service, it executes a probe processing scheme according to the messages from the probe. The probe processing scheme includes a multicast probe processing process and an RC-based point-to-point probe processing process.

[0089] In this embodiment, the probed end can establish a parent thread to start the listening probe service, and can also establish a thread 1 for performing multicast probe processing. Specifically, thread 1 can bind an IP address, port, protection domain (PD), and QPN. The RC queue initializes enqueue work queue entries (WQEs), and probe packet reception is performed based on the WQEs. To ensure that there are always WQEs in the queue, if there are 0 WQEs in the RC queue, then 2 WQEs are enqueued into the RC queue; otherwise, 1 WQE is enqueued into the RC queue for probe packet data processing to obtain received information. Furthermore, the probed end can also establish a thread 2 for performing point-to-point probe processing. Specifically, thread 2 can establish an RC connection, receive probe packets, and close the RC connection.

[0090] Figure 1The server cluster 100 in the text can be a server cluster or a distributed system composed of multiple physical servers, or it can be a cloud server cluster composed of cloud servers that provide basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms, but it is not limited to these.

[0091] Of course, the methods provided in this disclosure are not limited to... Figure 1 The application scenarios shown can also be used in other possible application scenarios, and this disclosure does not limit the scope of the embodiments.

[0092] To further illustrate the technical solutions provided by the embodiments of this disclosure, a detailed description is provided below in conjunction with the accompanying drawings and specific implementation methods. Although the embodiments of this disclosure provide method operation steps as shown in the following embodiments or drawings, the method may include more or fewer operation steps based on conventional or non-inventive methods. In steps where there is no logically necessary causal relationship, the execution order of these steps is not limited to the execution order provided by the embodiments of this disclosure. In actual processing or when the device executes the method, it may be executed sequentially or in parallel according to the method shown in the embodiments or drawings.

[0093] Please see Figure 2 , Figure 2 This is a flowchart illustrating a network latency analysis method according to an embodiment of this disclosure. The method can be executed, for example, by an electronic device, which can be... Figure 1 The specific implementation process of this method, executed on server cluster 100, is as follows:

[0094] Step 201: Based on the network topology, divide the devices in the cluster into at least one multicast group.

[0095] In this embodiment of the disclosure, the control terminal device within the server cluster can divide the devices within the cluster into at least one multicast group according to the network topology. That is, the devices within the cluster can be divided into one multicast group, or the devices within the cluster can be divided into multiple multicast groups, such as two multicast groups or three multicast groups, etc. The specific number of multicast groups can be determined according to the actual implementation situation, and this embodiment of the disclosure does not limit this.

[0096] Optionally, the control device can divide the devices within the cluster into at least one multicast group based on network topology and service allocation requirements. Network topology can be understood as cluster topology information, including node information, network topology structure, rack information, domain name system information, computing power information, etc. Service allocation requirements information includes, for example, which computing power and racks are needed to execute service 1. In other words, by dividing the devices within the cluster into multicast groups according to the actual service allocation requirements and the current cluster situation, any multicast group containing these devices can be understood as a group capable of executing a sub-service.

[0097] Optionally, the control device can also divide the entire cluster into at least one multicast group based on the cluster topology information and service allocation requirements, combined with Equal-Cost Multi-Path (ECMP) routing or other routing configurations. Therefore, in this embodiment, when dividing multicast groups, in addition to considering the cluster situation and service allocation, transmission issues are also taken into account, thereby ensuring the accuracy of multicast group division as much as possible and providing a good implementation foundation for the subsequent transmission of multicast probe packets.

[0098] In this embodiment, after the control device determines a multicast group, it can determine the first information of each multicast group. The first information includes the configuration information and the probe interval information of the multicast group. The configuration information of the multicast group can be understood as the identification information and quantity information of the devices included in the multicast group. The probe interval information can be understood as the interval between sending multicast probe packets to the multicast group. The probe interval information can be determined according to the actual implementation, for example, sending a multicast probe packet once every 3 seconds. This embodiment does not limit this.

[0099] In this embodiment of the disclosure, after the control terminal device determines the first information of each multicast group, it can send the first information to the detection processing device. Thus, both the detection terminal and the detected terminal in the detection processing device can listen to and obtain the first information. This ensures that the first information obtained by the detection processing device is the latest first information, avoiding the situation where the first information adjustment caused by the topology adjustment within the cluster is unknown, which may lead to network latency measurement errors.

[0100] Step 202: Send multicast probe packets to each multicast group using unreliable datagrams.

[0101] In this embodiment of the disclosure, when the probe end in the probe processing device listens to the first message triggered by the control end device, it can perform multicast probe based on UD.

[0102] In this embodiment of the disclosure, the probe end in the probe processing device sends multicast probe packets to the corresponding multicast group via UD, according to the multicast time interval corresponding to each multicast group; wherein each multicast probe packet contains an incrementing sequence number. The multicast time interval is a specific value corresponding to the probe interval information in the first information.

[0103] Step 203: Determine the reception information of each device in each multicast group for receiving multicast probe packets.

[0104] In this embodiment of the disclosure, the probed end in the detection processing device can start a listening service, which is used to receive first information from the control end and connection requests for point-to-point detection, thereby establishing a basic communication framework for subsequent detection activities.

[0105] In this embodiment of the disclosure, the probed end in the probed processing device performs the following operations for each multicast group: determining the number of devices in the multicast group, and establishing corresponding listening and queue numbering based on the number of devices in the multicast group to receive the corresponding multicast probe packets; after determining that a device in the multicast group has received the corresponding multicast probe packet, recording the address information, reception time information, and sequence number of the multicast probe packet; and determining the reception information of each device in the multicast group for receiving the multicast probe packet based on the recorded address information, reception time information, and sequence number of the multicast probe packet; wherein each reception information includes sequence number missing information and round-trip time information.

[0106] As can be seen, in this embodiment of the disclosure, the probed end in the probe processing device, which receives multicast probe information from UD (i.e., the aforementioned multicast probe packets), can start a separate thread. In this thread, firstly, a preset listening and queue pair number (QPN) setting is established based on the first information of the multicast group. Next, the receive queue is initialized and WQEs are added to the queue to ensure that the receive queue always has enough WQEs to process the received data, preventing the loss of multicast probe packets. Whenever a multicast probe packet is successfully received, the sender's IP address, the receive timestamp, and the sequence number within the packet are recorded. For example, {"IP1":{"index1":"time1","index2":"time2",...},...}. Furthermore, all data collected during the probe process can be integrated to obtain the received information, and then asynchronously reported to the control end for further analysis.

[0107] Optionally, for the popular ROCEv2 protocol in RDMA, the default listening is IP listening, and the corresponding IP address is recorded. For the IB (InfiniBand) and ROCEv1 protocols, the default listening is GID (Global Identifier) ​​or LID (Local Identifier) ​​listening, and the corresponding GID address or LID address is recorded.

[0108] Step 204: Determine network latency information based on the received information corresponding to each device in each multicast group.

[0109] In this embodiment of the disclosure, the control device can determine the summary reception information for each device in each multicast group based on the reception information corresponding to each device in each multicast group. Optionally, based on the reception information corresponding to each device in each multicast group, packet loss information and / or time interval information corresponding to packet loss for each device can be determined; the packet loss information and / or time interval information corresponding to packet loss for each device can be used as the summary reception information for each device.

[0110] In this embodiment of the disclosure, packet loss information can be understood as the number of times the probe packet is lost (sequence number is missing). That is, the loss information can be determined by the missing sequence number corresponding to the data in the multicast probe packet (i.e. the missing sequence number in the aforementioned recorded message).

[0111] In this embodiment of the disclosure, the time interval information corresponding to packet loss can be understood as the time interval Δt between adjacent sequence number detection packets being greater than 2 times. The number of times. Among them Where time interval The interval for sending multicast probe packets. To estimate the theoretical minimum link delay, we use the minimum Δt, i.e.

[0112]

[0113] In this embodiment of the disclosure, if the number of probe packet losses is greater than a first threshold, then the preset condition is determined to be met; or, if the time interval information corresponding to the packet loss is greater than a second threshold, then the preset condition is determined to be met; or, if the number of data packet losses (sequence number missing) and the time interval Δt between adjacent sequence number probe packets are greater than twice the threshold, then the preset condition is determined to be met. If the sum of the number of occurrences is greater than the third threshold, then the preset condition is satisfied.

[0114] In one optional implementation, when it is determined that the received summary information corresponding to the first device in the first multicast group meets the preset conditions, point-to-point probing is performed on the first device to obtain the probing result information; and the network latency information of the first device is determined based on the probing result information.

[0115] The detection results can be the average, maximum, or minimum round-trip time in the point-to-point detection data. If the detection results deviate significantly from the empirical values, for example, if the average, maximum, or minimum round-trip time in the point-to-point detection data is much greater than or much less than the empirical values, then it is determined that there is an anomaly in the network, indicating a potential performance bottleneck or link failure.

[0116] Optionally, the probe can perform point-to-point RC probing on the first device to obtain probe result information. That is, after the control unit analyzes historical data to identify potentially abnormal probed devices, it assigns the probe to perform RC point-to-point measurements with the potentially abnormal probed devices to obtain more accurate latency data (i.e., the aforementioned probe result information). The control unit can then determine the network latency information of the first device based on the probe result information.

[0117] Optionally, after the monitored service receives the peer-to-peer probe connection establishment request, the probed end negotiates a connection and starts a new thread to use RC for precise probing. During the probe, standard probing procedures such as Perftest or Qperf are run to exchange data packets and collect the average, maximum, and minimum RTT values. After data collection is complete, the RC connection is closed.

[0118] In one optional implementation, when it is determined that the received summary information corresponding to the second device in the first multicast group does not meet the preset conditions, network delay information is determined based on the received information corresponding to the second device.

[0119] As can be seen, in this embodiment, the method of determining network latency information using only one-way probe packets not only optimizes the sending and processing efficiency of probe packets, but also significantly reduces the network bandwidth required compared to the traditional fully connected probe mode, thus reducing network resource consumption. This can alleviate network congestion that may occur in large-scale cluster environments and effectively improve the overall network probe efficiency without sacrificing data accuracy. Furthermore, after determining the received information, the received information is further analyzed to determine whether to take further targeted point-to-point precise probes, ensuring the accuracy of network latency analysis while reducing network resource consumption.

[0120] The following is a specific example illustrating a network latency analysis method provided in this disclosure. Please refer to... Figure 3 The specific process steps are as follows:

[0121] Step 301: The control terminal divides the cluster into at least one multicast group based on the cluster topology information and service allocation requirements, and determines and sends the first information for each multicast group.

[0122] Step 302: Based on the first information of the multicast group that it has been listening to, the probe end uses UD to send multicast probe packets to the set multicast group at the multicast time interval. The multicast probe packet contains incrementing sequence number data.

[0123] Step 303: The probed end receives multicast probe packets in the WQE receiving queue set by the established IP listening and QPN, and records the probe end's IP address, receiving timestamp, and sequence number in the packet. Based on the probe end's IP address, receiving timestamp, and sequence number in the packet, the probed end determines the received information.

[0124] Step 304: The control terminal receives the reception information sent by the probed terminal and determines the corresponding reception summary information of the probed terminal based on the reception information.

[0125] Step 305: When the control terminal determines that the received summary information meets the preset conditions, it issues a point-to-point detection task.

[0126] Step 306: After the probe detects the point-to-point probe task, it performs RC-based point-to-point probe processing on the probed end.

[0127] Step 307: After the monitored service receives the connection establishment request for peer-to-peer probe, the probed end negotiates the connection and starts a new thread to use RC for precise probe and obtain probe result information.

[0128] Optionally, during the probing process, standard probing procedures such as Perftest or Qperf are run to exchange data packets and collect the average, maximum, and minimum RTT values ​​to obtain probing results. After data collection is complete, the RC connection can be closed.

[0129] Step 308: The control terminal receives the detection result information sent by the probed terminal and determines the network latency information of the probed terminal based on the detection result information.

[0130] Step 309: When the control terminal determines that the received summary information does not meet the preset conditions, it determines the network delay information of the probed terminal based on the received information.

[0131] As can be seen, in this embodiment, preliminary network probing is performed using UD (Unified Detection) and unidirectional multicast modes, i.e., multicast probing is performed first. This approach can reduce probing traffic and optimize resource allocation. Furthermore, after the preliminary multicast probing, combined with data analysis and evaluation from the control end, further targeted point-to-point precise probing is conducted. This hierarchical probing strategy not only ensures the efficient execution of probing tasks but also ensures the accuracy of network fault location and the speed of fault diagnosis and resolution through targeted allocation of hardware and software resources, thereby improving network reliability and quality of service.

[0132] Exemplary embodiments of this disclosure also provide a network latency analysis apparatus. (See reference...) Figure 4 As shown, the network latency analysis device 400 includes the following program modules:

[0133] The partitioning unit 401 is used to divide the devices in the cluster into at least one multicast group according to the network topology.

[0134] The sending unit 402 is configured to send multicast probe packets to each of the multicast groups respectively via unreliable datagrams;

[0135] The determining unit 403 is used to determine the reception information of each device in each multicast group when receiving the multicast probe packet;

[0136] The processing unit 404 is used to determine network delay information based on the received information corresponding to each device in each multicast group.

[0137] In one possible implementation, the partitioning unit 401 is specifically used for:

[0138] Based on network topology and service allocation requirements, the devices within the cluster are divided into at least one multicast group.

[0139] In one possible implementation, the processing unit 404 is specifically used for:

[0140] Based on the received information corresponding to each device in each multicast group, the received summary information corresponding to each device in each multicast group is determined;

[0141] When it is determined that the received summary information corresponding to the first device in the first multicast group meets the preset conditions, point-to-point detection processing is performed on the first device to obtain the detection result information;

[0142] Based on the detection results, the network latency information of the first device is determined.

[0143] In one possible implementation, the processing unit 404 is specifically used for:

[0144] Based on the received information of each device in each multicast group, determine the packet loss information and / or the time interval information corresponding to the packet loss of each device;

[0145] The packet loss information and / or the time interval information corresponding to the packet loss of each device are used as the summary reception information of each device.

[0146] In one possible implementation, the processing unit 404 is specifically used for:

[0147] If it is determined that the received summary information corresponding to the second device in the first multicast group does not meet the preset conditions, then the network delay information is determined based on the received information corresponding to the second device.

[0148] In one possible implementation, the sending unit 402 is specifically used for:

[0149] Using unreliable datagrams, multicast probe packets are sent to the corresponding multicast groups according to the multicast time interval; wherein each multicast probe packet contains an incrementing sequence number.

[0150] In one possible implementation, the determining unit 403 is specifically used for:

[0151] For each of the multicast groups, perform the following operations:

[0152] Determine the number of devices in the multicast group, and based on the number of devices in the multicast group, establish corresponding listening and queue pairs with numbering settings to receive the corresponding multicast probe packets;

[0153] Once it is determined that a device within the multicast group has received the corresponding multicast probe packet, the address information, reception time information, and sequence number of the multicast probe packet are recorded.

[0154] Based on the recorded address information, reception time information, and sequence number of the multicast probe packet sent, the reception information of each device in the multicast group for receiving the multicast probe packet is determined; wherein, each reception information includes sequence number missing information and round-trip time information.

[0155] The specific details of each part of the above-mentioned device have been described in detail in the method section of the implementation plan. For any undisclosed details, please refer to the implementation plan of the method section, and therefore will not be repeated here.

[0156] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to exemplary embodiments of this 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 and embodied by multiple modules or units.

[0157] An exemplary embodiment of this disclosure also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, implements the network latency analysis method described above.

[0158] In one embodiment, the computer program product can be a tangible product containing a computer program, such as a computer-readable storage medium storing the computer program. The readable storage medium can be a storage medium based on electrical, magnetic, optical, electromagnetic, infrared, or other signals, including but not limited to: random access memory (RAM), read-only memory (ROM), magnetic tape, floppy disk, flash memory, hard disk drive (HDD), solid-state drive (SSD), etc. For example, the computer program product can be implemented as a non-volatile storage medium storing the computer program, such as read-only memory, NAND flash memory, etc.

[0159] In one implementation, the computer program product can be an intangible product containing a computer program. For example, the computer program product can be implemented as a virtual digital product, such as an executable file, installation package, or other digital file storing the computer program.

[0160] Computer program code can be written in one or more programming languages. Examples of programming languages ​​include C, Java, and C++. Program code can execute entirely on the user's computing device, partially on the user's computing device, or as a standalone software package. It can also execute partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, such as a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via an internet connection provided by a mobile network operator).

[0161] Computer programs can be carried or transmitted via signals such as electricity, magnetism, light, electromagnetic radiation, and infrared radiation. Electronic devices can convert signals carrying computer programs into digital signals, thereby running the computer programs. When a computer program runs on an electronic device, its code causes the electronic device to execute (more specifically, its processor) the method steps of various exemplary embodiments of this disclosure, such as the network latency analysis method described above, which includes the following steps:

[0162] Step 201: Divide the devices in the cluster into at least one multicast group according to the network topology; Step 202: Send multicast probe packets to each multicast group using unreliable datagrams; Step 203: Determine the reception information of each device in each multicast group that receives the multicast probe packets; Step 204: Determine the network latency information based on the reception information of each device in each multicast group.

[0163] The above method steps are implemented by a computer program. Based on the network topology, the devices within the cluster are divided into at least one multicast group. Multicast probe packets are sent to each multicast group using unreliable datagrams. The reception information of each device within each multicast group is determined. Finally, network latency information is determined based on the reception information of each device within each multicast group. It is evident that this embodiment of the invention, by using only one-way probe packets to determine network latency information, not only ensures the performance of determining network latency but also reduces the consumption of network and computing resources, avoiding latency and packet loss caused by excessive network resource consumption.

[0164] Exemplary embodiments of this disclosure also provide an electronic device, which may include a processor and a memory. The memory stores executable instructions for the processor, such as computer programs. The processor executes the executable instructions to perform the method steps of various exemplary embodiments of this disclosure.

[0165] The following is for reference. Figure 4 The electronic device is illustrated by way of a general-purpose computing device. It should be understood that... Figure 4 The electronic device 400 shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments disclosed herein.

[0166] like Figure 5 As shown, the electronic device 500 may include: a processor 510, a memory 520, a bus 530, an I / O (input / output) interface 540, and a network adapter 550.

[0167] The memory 520 may include volatile memory, such as RAM 521 and cache unit 522, and may also include non-volatile memory, such as ROM 523. The memory 520 may also include one or more program modules 524, including but not limited to: an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. For example, program module 524 may include the modules described above.

[0168] The processor 510 may include one or more processing units, such as an AP (Application Processor), a modem processor, a GPU (Graphics Processing Unit), an ISP (Image Signal Processor), a controller, an encoder, a decoder, a DSP (Digital Signal Processor), a baseband processor, and / or an NPU (Neural-Network Processing Unit).

[0169] The processor 510 can be used to execute executable instructions stored in the memory 520, such as the network latency analysis method described above, which includes the following steps: Step 201: Divide the devices in the cluster into at least one multicast group according to the network topology; Step 202: Send multicast probe packets to each multicast group respectively via unreliable datagrams; Step 203: Determine the reception information of each device in each multicast group that receives the multicast probe packets; Step 204: Determine the network latency information according to the reception information of each device in each multicast group.

[0170] The processor 510 executes the above method steps, dividing the devices within the cluster into at least one multicast group according to the network topology; sending multicast probe packets to each multicast group using unreliable datagrams; determining the reception information of each device in each multicast group for receiving the multicast probe packets; and finally determining the network latency information based on the reception information corresponding to each device in each multicast group. It is evident that this embodiment of the present disclosure, by using only one-way probe packets to determine network latency information, not only ensures the performance of determining network latency but also reduces the consumption of network and computing resources, avoiding latency and packet loss caused by excessive network resource consumption.

[0171] Bus 530 is used to connect different components of electronic device 500 and may include a data bus, an address bus and a control bus.

[0172] Electronic device 500 can communicate with one or more external devices 600 (such as keyboard, mouse, external controller, etc.) through I / O interface 540.

[0173] Electronic device 500 can communicate with one or more networks via network adapter 550. For example, network adapter 550 can provide mobile communication solutions such as 3G / 4G / 5G, or wireless communication solutions such as wireless LAN, Bluetooth, and near-field communication. Network adapter 550 can communicate with other modules of electronic device 500 via bus 530.

[0174] although Figure 5 As not shown in the diagram, other hardware and / or software modules may also be configured in the electronic device 500, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0175] As can be seen from the above, the technical solutions disclosed herein can be implemented as methods, apparatus, systems, computer program products, storage media, electronic devices, etc. Those skilled in the art will understand that various aspects of this disclosure can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software implementations, which may be referred to as "circuit," "module," or "system," respectively.

[0176] It should be understood that this disclosure is not limited to the specific methods, steps, or structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. Those skilled in the art will readily conceive of other embodiments based on the specific implementations provided in this disclosure. Therefore, the specific implementations provided in this disclosure are merely exemplary, and the scope and spirit of this disclosure are indicated by the claims, and should cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary technical means in the art not disclosed in this disclosure.

Claims

1. A network latency analysis method, characterized in that, The method includes: Based on the network topology, the devices within the cluster are divided into at least one multicast group; Multicast probe packets are sent to each of the multicast groups using unreliable datagrams. Determine the reception information of each device within each multicast group for receiving the multicast probe packet; Based on the received information corresponding to each device within each multicast group, network latency information is determined; The step of determining network latency information based on the reception time information of each device within each multicast group includes: Based on the received information corresponding to each device in each multicast group, the received summary information corresponding to each device in each multicast group is determined; When it is determined that the received summary information corresponding to the first device in the first multicast group meets the preset conditions, point-to-point detection processing is performed on the first device to obtain the detection result information; Based on the detection results, the network latency information of the first device is determined.

2. The method according to claim 1, characterized in that, Based on the network topology, the devices within the cluster are divided into at least one multicast group, including: Based on network topology and service allocation requirements, the devices within the cluster are divided into at least one multicast group.

3. The method according to claim 1, characterized in that, Based on the reception time information of each device within each multicast group, determine the summary reception information for each device within each multicast group, including: Based on the received information of each device in each multicast group, determine the packet loss information and / or the time interval information corresponding to the packet loss of each device; The packet loss information and / or the time interval information corresponding to the packet loss of each device are used as the summary reception information of each device.

4. The method according to claim 1, characterized in that, The method further includes: If it is determined that the received summary information corresponding to the second device in the first multicast group does not meet the preset conditions, then the network delay information is determined based on the received information corresponding to the second device.

5. The method according to any one of claims 1-4, characterized in that, Multicast probe packets are sent to each of the multicast groups via unreliable datagrams, including: Using unreliable datagrams, multicast probe packets are sent to the corresponding multicast groups according to the multicast time interval; wherein each multicast probe packet contains an incrementing sequence number.

6. The method according to claim 5, characterized in that, Determine the reception information of each device within each multicast group that receives the multicast probe packet, including: For each of the multicast groups, perform the following operations: Determine the number of devices in the multicast group, and based on the number of devices in the multicast group, establish corresponding listening and queue pairs with numbering settings to receive the corresponding multicast probe packets; Once it is determined that a device within the multicast group has received the corresponding multicast probe packet, the address information, reception time information, and sequence number of the multicast probe packet are recorded. Based on the recorded address information, reception time information, and sequence number of the multicast probe packet sent, the reception information of each device in the multicast group for receiving the multicast probe packet is determined; wherein, each reception information includes sequence number missing information and round-trip time information.

7. A network latency analysis device, characterized in that, The device includes: A partitioning unit is used to divide devices within a cluster into at least one multicast group based on the network topology. The sending unit is configured to send multicast probe packets to each of the multicast groups respectively via unreliable datagrams; A determining unit is used to determine the reception information of each device in each multicast group when it receives the multicast probe packet; The processing unit is used to determine network delay information based on the received information corresponding to each device in each multicast group; Specifically, the processing unit is used for: Based on the received information corresponding to each device in each multicast group, the received summary information corresponding to each device in each multicast group is determined; When it is determined that the received summary information corresponding to the first device in the first multicast group meets the preset conditions, point-to-point detection processing is performed on the first device to obtain the detection result information; Based on the detection results, the network latency information of the first device is determined.

8. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1-6.

9. An electronic device, characterized in that, include: processor; Memory for storing the executable instructions of the processor; The processor is configured to perform the method of any one of claims 1-6 by executing the executable instructions.

Images