Network card time synchronization, transmission delay analysis method, device, storage medium and program product

Abstract

Embodiments of the present application provide a network card time synchronization method, a transmission delay analysis method, equipment, a storage medium and a program product. In the network card time synchronization method, the physical network card driver can accurately map the hardware receiving time stamp to the time domain of the software clock of the virtual machine according to the latest time difference between the software clock of the dynamically tracked virtual machine and the hardware clock of the physical network card, effectively compensating for the accumulated error caused by the clock drift between the physical network card and the virtual machine. Thus, without relying on the PTP protocol for clock calibration, the hardware time of the physical network card and the software time of the virtual machine can be aligned at a lower cost, so as to accurately analyze the delay points on the transmission path of the data packet in the same time domain. Even if a large number of virtual machines (tenants) in the cloud computing environment are not deployed with the PTP protocol, network delay analysis and performance observation can be accurately performed.

Description

Technical Field

[0001] This application relates to the field of cloud network technology, and in particular to a network card time synchronization, transmission delay analysis method, device, storage medium and program product. Background Technology

[0002] When analyzing network packet processing latency, it's crucial to determine whether the performance bottleneck lies at the hardware or software level. Some solutions identify network packet processing latency by comparing the hardware timestamp of the Network Interface Card (NIC) with the software timestamp generated by the NIC driver. Obtaining the software timestamp generated by the NIC driver is relatively straightforward. The NIC driver typically uses the time provided by the Operating System (OS) during packet reception or transmission, such as CLOCK_MONOTONIC (monotonic clock time) or CLOCK_REALTIME (system real-time time). The NIC's hardware timestamp, however, is provided by the NIC's hardware clock. However, the NIC's hardware clock and the operating system's clock often drift due to frequency differences.

[0003] To accurately pinpoint network latency bottlenecks, the network interface card's (NIC) hardware clock needs to be aligned with the operating system's clock for effective comparison within the same time domain. Traditional solutions rely on Precision Time Protocol (PTP) to align the NIC's hardware clock with the operating system's clock. However, to ensure synchronization accuracy, PTP depends on a complex master-slave negotiation mechanism. This results in significant hardware and computing resource consumption for each additional synchronization domain (i.e., each additional tenant), making it difficult to support the scalable expansion of cloud platforms. Therefore, a new solution is needed. Summary of the Invention

[0004] This application provides a network interface card (NIC) time synchronization and transmission delay analysis method, device, storage medium, and program product to align the hardware time of the physical NIC with the software time of the virtual machine at a lower cost, so as to accurately analyze the delay points on the transmission path of data packets in the same time domain.

[0005] This application provides a physical network interface card (NIC) time synchronization method, applied to a physical NIC driver on a physical machine. At least one virtual machine runs on the physical machine, and the NIC driver is located between the physical NIC of the physical machine and the operating system of the at least one virtual machine. The method includes: receiving a first data packet sent by the physical NIC, the first data packet carrying an original hardware receive timestamp added by the physical NIC, and the first data packet pointing to a first virtual machine; mapping the original hardware receive timestamp to the time domain corresponding to the software clock based on the latest time difference between the dynamically tracked software clock of the first virtual machine and the hardware clock of the physical NIC, to obtain a corrected hardware receive timestamp; adding a software receive timestamp to the first data packet according to the software clock of the first virtual machine, and sending the first data packet to the first virtual machine; providing the corrected hardware timestamp to the first virtual machine so that a target application on the first virtual machine can analyze the processing delay points on the reception path of the first data packet based on the software receive timestamp and the corrected hardware receive timestamp.

[0006] Optionally, it further includes: synchronously collecting the value of the hardware clock of the physical network card and the value of the software clock of the at least one virtual machine according to a set sampling period; and determining the latest time difference between the software clock of the at least one virtual machine and the hardware clock of the physical network card according to a set update period based on the synchronously collected values ​​of the hardware clock of the physical network card and the software clock of the at least one virtual machine.

[0007] Optionally, the update cycle is the same as the sampling cycle and is synchronized in time; according to the set update cycle, based on the hardware clock of the physical network card and the software clock of the at least one virtual machine synchronously collected, the latest time difference of the software clock of the at least one virtual machine relative to the hardware clock of the physical network card is determined, including: for any virtual machine among the at least one virtual machine, when any current update cycle arrives, based on the value of the hardware clock and the value of the software clock synchronously sampled in the current update cycle, the time difference corresponding to the current update cycle is determined as the latest time difference of the software clock of the virtual machine relative to the hardware clock of the physical network card.

[0008] Optionally, according to a set update cycle, based on the synchronously collected hardware clock value of the physical network interface card and the software clock value of the at least one virtual machine, the latest time difference between the software clock of the at least one virtual machine and the hardware clock of the physical network interface card is determined, including: for any virtual machine among the at least one virtual machine, when any current update cycle arrives, calculating the time difference sequence corresponding to the multiple sampling times based on the sequence values ​​of the hardware clock and the sequence values ​​of the software clock synchronously sampled at multiple sampling times in the current update cycle; fitting a linear model of the time difference corresponding to the current update cycle changing with the value of the hardware clock based on the multiple sampling times and their corresponding time difference sequences; and predicting the latest time difference between the software clock of the virtual machine and the hardware clock of the physical network interface card based on the linear model of the time difference changing with the value of the hardware clock.

[0009] Optionally, the method further includes: receiving a second data packet sent by a second virtual machine; adding a software transmission timestamp to the second data packet according to the software clock of the second virtual machine; forwarding the second data packet to the physical network interface card (NIC) so that the NIC sends the second data packet to the destination and returns a transmission completion notification message, the notification message containing the original hardware transmission timestamp added by the NIC when sending the second data packet; mapping the original hardware transmission timestamp to the time domain corresponding to the software clock according to the latest time difference between the software clock of the second virtual machine and the hardware clock of the NIC, to obtain a corrected hardware transmission timestamp; adding the corrected hardware transmission timestamp to the transmission completion queue of the NIC so that a target application in the operating system of the second virtual machine reads the corrected hardware transmission timestamp from the completion queue through a specified interface, the corrected hardware transmission timestamp and the software transmission timestamp being used to analyze the processing delay points on the transmission path of the second data packet.

[0010] Optionally, it further includes: adding the corrected hardware receive timestamp to a target data structure in the kernel of the first virtual machine, so that the target application in the first virtual machine reads the corrected hardware receive timestamp from the target data structure and analyzes the processing delay point on the reception path of the first data packet based on the corrected hardware receive timestamp and the software receive timestamp.

[0011] This application also provides a physical network interface card (NIC) time synchronization method, applied to a physical NIC driver on a physical machine, wherein at least one virtual machine runs on the physical machine, and the physical NIC driver is located between the physical NIC of the physical machine and the operating system of the at least one virtual machine; the method includes: receiving a data packet sent by any virtual machine; adding a software sending timestamp to the data packet according to the software clock of the virtual machine; forwarding the data packet to the physical NIC so that the physical NIC sends the data packet to the destination and returns a sending completion notification message, the notification message containing the original hardware sending timestamp added by the physical NIC when sending the data packet; mapping the original hardware sending timestamp to the time domain corresponding to the software clock according to the latest time difference between the hardware clock of the physical NIC and the software clock of the virtual machine to obtain a corrected hardware sending timestamp; adding the corrected hardware sending timestamp to the sending completion queue of the physical NIC so that a target application in the operating system of the virtual machine reads the corrected hardware sending timestamp from the completion queue through a specified interface, the corrected hardware sending timestamp and the software sending timestamp being used to analyze the processing delay points on the sending path of the data packet.

[0012] This application also provides a transmission delay analysis method, applied to a target application in the operating system of a virtual machine, wherein the virtual machine is any virtual machine running on a physical machine; the virtual machine transmits data with an external network through a physical network card driver and a physical network card on the physical machine; the method includes: obtaining a software receive timestamp and a corrected hardware receive timestamp of a first data packet pointing to a first virtual machine, wherein the software receive timestamp is added by the physical network card driver on the physical machine according to the software clock of the first virtual machine when the first data packet is received; the corrected hardware receive timestamp is obtained by the physical network card driver mapping the original hardware receive timestamp to the time domain corresponding to the software clock according to the latest time difference between the software clock of the first virtual machine and the hardware clock of the physical network card, wherein the original hardware receive timestamp is added by the physical network card when the first data packet is received; and analyzing the processing delay points on the reception path of the first data packet based on the software receive timestamp and the hardware receive timestamp.

[0013] Optionally, it further includes: obtaining a software transmission timestamp added by the operating system of the first virtual machine when sending the first data packet; reading the corrected hardware transmission timestamp of the first data packet from the completion queue of the physical network card through a specified interface, wherein the corrected hardware transmission timestamp is obtained by the physical network card driver mapping the original hardware transmission timestamp to the time domain corresponding to the software clock based on the latest time difference between the software clock of the first virtual machine and the hardware clock of the physical network card, and the original hardware transmission timestamp is added by the physical network card when sending the first data packet; and analyzing the processing delay points on the transmission path of the first data packet based on the software reception timestamp and the corrected hardware transmission timestamp.

[0014] This application also provides a physical machine on which at least one virtual machine runs. The physical network card driver on the physical machine is located between the physical network card of the physical machine and the operating system of the at least one virtual machine. The physical network card driver is used to execute the physical network card time synchronization method provided in this application, and the target application running on any of the at least one virtual machine is used to execute the transmission delay analysis method provided in this application.

[0015] This application also provides a computer cluster, which includes at least one physical machine provided in this application.

[0016] This application also provides an electronic device, including: a memory and a processor; the memory is used to store one or more computer instructions; the processor is used to execute the one or more computer instructions to perform the steps in the method provided in this application.

[0017] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the steps in the method provided in this application.

[0018] This application also provides a computer program product, including: a computer program / instructions, which, when executed by a processor, can implement the steps in the method provided in this application.

[0019] In this embodiment, the physical network interface card (NIC) driver can adjust the hardware receive timestamp added to data packets by the physical NIC based on the time difference between the dynamically tracked virtual machine's software clock and the physical NIC's hardware clock. This accurately maps the hardware receive timestamp to the time domain of the virtual machine's software clock, effectively compensating for accumulated errors caused by clock drift between the physical NIC and the virtual machine. Therefore, on the data reception path, the hardware time of the physical NIC and the software time of the virtual machine can be aligned at a lower cost without relying on the PTP protocol for clock calibration, facilitating accurate analysis of latency points on the data packet transmission path within the same time domain. On the one hand, by reducing the reliance of network diagnostics on the PTP protocol, even if a large number of virtual machines (tenants) in the cloud computing environment do not deploy the PTP protocol, accurate network latency analysis and performance observation can still be performed. On the other hand, virtual machines (tenants) on a physical machine share the same physical network interface card (NIC). The physical clock of this NIC is a globally unified time reference source that is independent of the virtual machine (tenant). The physical NIC driver can achieve time domain synchronization by maintaining the time difference between the physical clock and the software clock of the virtual machine (tenant). This eliminates the need to rely on PTP hardware to allocate independent hardware PTP resources (such as dedicated timers or on-chip storage resources) for each virtual machine (tenant), which greatly reduces hardware overhead and effectively improves the elastic scalability and resource utilization of the cloud computing platform. Attached Figure Description

[0020] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 A flowchart illustrating a network interface card (NIC) time synchronization method provided as an exemplary embodiment of this application; Figure 2 This is a schematic diagram illustrating network interface card (NIC) time synchronization along a data transmission path, provided as an exemplary embodiment of this application. Figure 3 This is a flowchart illustrating a transmission delay analysis method provided in an exemplary embodiment of this application; Figure 4 A schematic diagram of the structure of an electronic device provided in an exemplary embodiment of this application. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the application. The singular forms “a,” “the,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. “Multiple” generally includes at least two, but does not exclude the inclusion of at least one. “A plurality” generally includes at least two, but does not exclude the inclusion of at least one.

[0023] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0024] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a product or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a product or system. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the product or system that includes said element.

[0025] In a multi-tenant architecture of cloud computing, a single physical server (host machine) can simultaneously host dozens to hundreds of isolated virtual machines (VMs) using virtualization technologies such as KVM. These VMs constitute the basic computing units of the cloud platform, providing logically independent operating environments for different users. Based on this isolation characteristic, the cloud platform typically assigns one or more VMs to specific tenants (i.e., users or enterprises). Each VM is like an independent physical computer, running a complete operating system (Guest OS), and is configured by the virtualization platform with a virtual network interface card (vNIC) with independent MAC (Media Access Control) and IP (Internet Protocol) addresses.

[0026] Virtual network interface cards (NICs) rely on the physical network interface card (pNIC) on the host machine to communicate with the outside world. When an application within the virtual machine sends a data packet, the data is first submitted to the virtual NIC driver by the Guest OS. The driver writes the data to memory and notifies the host machine's virtual switch (vSwitch). In a cloud computing environment, the vSwitch not only forwards the data but also typically performs overlay encapsulation on the data packets according to network policies to identify tenants and achieve logical isolation. The encapsulated data packets are then forwarded to the host machine's physical NIC driver, which uses DMA (Direct Memory Access) technology to transfer the data to the physical NIC. Finally, the physical NIC converts the data into electrical signals and sends them to the physical network.

[0027] Conversely, when the physical network interface card (NIC) receives external data, it writes the data to memory via DMA and notifies the physical NIC driver through interrupts or polling. The driver uploads the data to the virtual switch, where vSwitch strips the overlay and looks up the data in a table based on the inner address to accurately deliver the data to the virtual NIC driver of the target virtual machine. Finally, the Guest OS passes the data to the application.

[0028] In cloud computing environments, PTP-based clock alignment schemes have significant limitations. To ensure synchronization accuracy, PTP relies on a complex master-slave negotiation mechanism, which requires significant hardware and computing resources to add each synchronization domain (i.e., each additional tenant), making it difficult to support the large-scale expansion of cloud platforms.

[0029] Specifically, PTP-based time synchronization solutions face the following challenges in cloud networks: First, the PTP protocol has poor deployment compatibility in cloud network environments. The core of PTP's microsecond or even nanosecond precision lies in hardware timestamps, meaning the network interface card (NIC) must timestamp data packets the instant they enter or leave the physical port. However, in cloud computing environments, tenants typically use virtual NICs. If the underlying physical NIC does not support SR-IOV (Single Root I / O Virtualization) pass-through, or if the virtual switch cannot process hardware timestamps at the virtual layer, PTP packets can only be software-tagged by the CPU (Central Processing Unit). This introduces operating system scheduling and interrupt latency, causing the precision to instantly degrade to the millisecond level, thus negating the value of introducing PTP. Furthermore, the tenant's operating system is a "black box" for cloud vendors; vendors cannot force tenants to enable PTP services or configure the correct drivers. If the tenant's OS does not have a PTP daemon configured, or uses an outdated image that does not support PTP, the synchronization link will break at the "last hop."

[0030] Secondly, the PTP protocol suffers from high state maintenance overhead and low resource scalability. The PTP protocol includes the Best Master Clock Algorithm (BMCA), port state machines (initialization, listening, slave, master states, etc.), and complex delayed request / response mechanisms. Each PTP instance needs to independently maintain a complete state machine and computational logic. To provide each tenant with an independent, isolated time synchronization domain, a separate PTP state machine must be run for each tenant. When thousands of tenants are running on a cloud platform, it is difficult to allocate independent hardware PTP resources (such as dedicated timers or on-chip storage resources) to each tenant, which greatly limits the elastic scalability of the cloud platform.

[0031] To address the aforementioned technical problems, a solution is provided in some embodiments of this application. The technical solutions provided by each embodiment of this application are described in detail below with reference to the accompanying drawings.

[0032] Figure 1 This is a flowchart illustrating a network interface card (NIC) time synchronization method provided in an exemplary embodiment of this application. The method may include, for example: Figure 1 The steps shown are as follows: Step 101: The physical network card driver receives the first data packet sent by the physical network card. The first data packet carries the original hardware receive timestamp added by the physical network card and points to the first virtual machine.

[0033] Step 102: Based on the latest time difference between the software clock of the first virtual machine and the hardware clock of the physical network card, the original hardware receiving timestamp is mapped to the time domain corresponding to the software clock to obtain the corrected hardware receiving timestamp.

[0034] Step 103: Add a software receiving timestamp to the first data packet according to the software clock of the first virtual machine, and send the first data packet to the first virtual machine.

[0035] Step 104: Provide the corrected hardware timestamp to the first virtual machine so that the target application on the first virtual machine can analyze the processing delay point on the receiving path of the first data packet based on the software receiving timestamp and the corrected hardware receiving timestamp.

[0036] The execution entity in this embodiment is the physical network interface card (NIC) driver on the physical machine. At least one virtual machine runs on the physical machine, and the NIC driver resides between the physical NIC and the operating system of the at least one virtual machine. This at least one virtual machine can be used as a cloud computing service instance (i.e., a cloud host) or run independently in a non-cloud environment; this embodiment does not impose any restrictions. In a virtualized environment, when a virtual machine needs to send data, the data sequentially passes through the virtual NIC, virtual switch, the physical machine's kernel protocol stack, the NIC driver, and the physical NIC again, finally reaching the external network. The NIC driver is responsible for efficiently sending the data stream from the virtual machine through the physical NIC. When data from the external network is sent to a virtual machine, the physical NIC receives the signal. After receiving this data, the physical NIC driver forwards the data to the corresponding virtual switch based on the virtual machine's MAC address or IP address, ultimately delivering it to the virtual machine.

[0037] In this embodiment, the physical network card driver is mainly used to correct the transmission time of data packets when exchanging data packets between the virtual machine and the physical network card, based on the time difference between the hardware clocks of the virtual machine and the physical network card, so as to facilitate the analysis of the transmission delay points of data packets in the same time domain.

[0038] In step 101, the first data packet refers to any data packet sent by the physical network card to the physical network card driver. The term "first data packet" is used here to describe this data packet only for easy differentiation from subsequent data packets and does not restrict the order or number of data packets. The first data packet is received by the physical network card from the external network. When the physical network card receives the first data packet from the external network, it adds a reception timestamp to the first data packet, which is marked here as the original hardware reception timestamp. Optionally, the physical network card can add the original reception timestamp to the descriptor corresponding to the first data packet. When processing the first data packet, the physical network card driver can read the original hardware timestamp from the descriptor of the first data packet. The first data packet may carry a destination MAC address or a destination IP address, and the virtual machine on the physical machine corresponding to the destination MAC address or destination IP address can be marked as the first virtual machine.

[0039] To synchronize the physical network interface card's (NIC) time with the virtual machine's operating system time, the NIC driver dynamically maintains the latest time difference between each virtual machine's software clock and the physical NIC's hardware clock. For example... Figure 2 As shown, the physical network card driver can obtain the latest time difference between the physical network card and the operating system based on the timestamp of the physical network card's hardware clock and the timestamp of the virtual machine's software clock. Based on this, in step 102, the physical network card driver can adjust the original hardware receiving timestamp according to the latest time difference between the first virtual machine's software clock and the physical network card's hardware clock to obtain a corrected hardware receiving timestamp. Adjusting the original hardware timestamp includes adding the time difference to the original hardware receiving timestamp so that the obtained corrected hardware receiving timestamp is in the same time domain as the first virtual machine's software clock.

[0040] In step 103, the physical network card driver can add a software reception timestamp to the first data packet based on the software clock of the first virtual machine. The virtual machine's software clock refers to the clock system maintained and managed by the kernel of the operating system (Guest OS) inside the virtual machine. The underlying time source of this software clock is not a physical crystal oscillator, but rather simulated or transmitted by the virtualization layer (Hypervisor, such as KVM or VMware). The software reception timestamp is used to compare with the corrected hardware reception timestamp to analyze the processing delay points on the reception path of the first data packet. The physical network card driver can then send the first data packet to the operating system of the first virtual machine to complete the transmission operation of the first data packet.

[0041] In step 104, the physical network card driver can provide a corrected hardware timestamp to the first virtual machine. A target application runs on the operating system of the first virtual machine. This target application analyzes the processing latency points on the transmission path of the data packets based on the software receive timestamp and the corrected hardware timestamp. The target application can be the destination program of the first data packet or a program dedicated to latency analysis running on the operating system of the first virtual machine; this embodiment is not limited. In some optional embodiments, the physical network card driver can add the corrected hardware receive timestamp to the first data packet to provide the corrected hardware receive timestamp to the target application through the first data packet. In other embodiments, the physical network card driver can add the corrected hardware receive timestamp to a target data structure in the kernel of the first virtual machine, so that the target application in the first virtual machine can read the corrected hardware receive timestamp from the target data structure. Optionally, the target data structure can be a socket buffer in the operating system kernel, from which the target application obtains the corrected hardware receive timestamp corresponding to the first data packet; this embodiment is not limited. Figure 2 As shown, the target application in the operating system of the first virtual machine can obtain the first data packet and the corrected hardware receiving timestamp, and can analyze the processing delay points on the receiving path of the first data packet based on the software receiving timestamp and the corrected hardware receiving timestamp of the first data packet.

[0042] In this embodiment, the physical network interface card (NIC) driver can adjust the hardware receive timestamp added to data packets by the physical NIC based on the time difference between the dynamically tracked virtual machine's software clock and the physical NIC's hardware clock. This accurately maps the hardware receive timestamp to the time domain of the virtual machine's software clock, effectively compensating for accumulated errors caused by clock drift between the physical NIC and the virtual machine. Therefore, on the data reception path, the hardware time of the physical NIC and the software time of the virtual machine can be aligned at a lower cost without relying on the PTP protocol for clock calibration, facilitating accurate analysis of latency points on the data packet transmission path within the same time domain. On the one hand, by reducing the reliance of network diagnostics on the PTP protocol, even if a large number of virtual machines (tenants) in the cloud computing environment do not deploy the PTP protocol, accurate network latency analysis and performance observation can still be performed. On the other hand, virtual machines (tenants) on a physical machine share the same physical network interface card (NIC). The physical clock of this NIC is a globally unified time reference source that is independent of the virtual machine (tenant). The physical NIC driver can achieve time domain synchronization by maintaining the time difference between the physical clock and the software clock of the virtual machine (tenant). This eliminates the need to rely on PTP hardware to allocate independent hardware PTP resources (such as dedicated timers or on-chip storage resources) for each virtual machine (tenant), which greatly reduces hardware overhead and effectively improves the elastic scalability and resource utilization of the cloud computing platform.

[0043] In some exemplary embodiments, the physical network interface card (NIC) driver can dynamically maintain the latest time difference between the software clock of the at least one virtual machine and the hardware clock of the physical NIC. When adjusting the original hardware receive timestamp based on the time difference between the software clock of the first virtual machine and the hardware clock of the physical NIC, the physical NIC driver can read the latest time difference between the software clock of the first virtual machine and the hardware clock of the physical NIC, and adjust the original hardware receive timestamp based on the latest time difference, thereby mapping the original hardware receive timestamp to the time domain corresponding to the software clock.

[0044] Optionally, the physical network interface card (NIC) driver can synchronously collect the hardware clock value of the physical NIC and the software clock value of the at least one virtual machine according to a set sampling period. Synchronous collection means collecting the hardware clock value of the physical NIC and the software clock value of the virtual machine at the same time to compare their differences. The physical NIC driver can determine the latest time difference between the software clock of the at least one virtual machine and the hardware clock of the physical NIC according to a set update period, based on the synchronously collected hardware clock values ​​of the physical NIC and the software clock values ​​of the at least one virtual machine. In this embodiment, the update period can be set according to the stability and accuracy requirements of the physical crystal oscillator of the physical NIC. For example, the update period can be set to 0.5 to 2 seconds, that is, the latest time difference between the software clock of the virtual machine and the hardware clock of the physical NIC can be updated every 0.5 to 2 seconds. In each update period, the time difference calculated in the current update period can replace the time difference calculated in the previous update period to dynamically update the latest time difference.

[0045] Based on this implementation, the physical network interface card (NIC) driver can periodically sample the hardware clock of the physical NIC and the software clock of the virtual machine using a dynamic synchronization mechanism, and periodically update the difference between the two. This achieves dynamic tracking of the offset between the physical clock and the software clock, thus facilitating effective compensation for accumulated errors caused by clock drift. Compared to the scheme of sampling and calibrating the physical clock and software clock all at once, this dynamic tracking scheme can ensure long-term accuracy and robustness in the conversion of hardware timestamps to the software time domain.

[0046] In some optional embodiments, the update period for the latest time difference is equal to the sampling period for sampling the hardware clock and the software clock, and the update period is time-synchronized with the sampling period. That is, the latest time difference between the hardware clock and the software clock is updated once each pair of hardware clocks and software clocks are sampled.

[0047] Taking any virtual machine and any current update cycle as an example, optionally, when any current update cycle arrives, the physical network card driver can determine the time difference corresponding to the current update cycle based on the value of the hardware clock and the value of the software clock synchronously sampled within the current update cycle. This time difference is used as the latest time difference between the virtual machine's software clock and the physical network card's hardware clock. For example, if both the update cycle and the sampling cycle are set to 0.5 to 2 seconds, the physical network card driver can sample the value of the virtual machine's software clock and the value of the physical network card's hardware clock every 0.5 to 2 seconds, and update the latest time difference between the virtual machine's software clock and the physical network card's hardware clock based on the sampled values.

[0048] In this implementation, the physical network card driver can quickly update the latest time difference between the virtual machine's software clock and the physical network card's hardware clock through clock acquisition and time difference calculation operations without relying on the PTP protocol, thereby effectively reducing the alignment overhead and alignment time of different time domains.

[0049] In some alternative embodiments, the physical network interface card (NIC) driver can sample the hardware clock and software clock multiple times and fit a linear model of the time difference as a function of the hardware clock value based on the results of these multiple samplings. This linear model can then be used to predict the latest time difference between the hardware clock and the software clock in real time.

[0050] Taking any virtual machine and any current update cycle as an example, optionally, when any current update cycle arrives, the physical network card driver can calculate the time difference sequence corresponding to the multiple sampling times based on the sequence values ​​of the hardware clock and the software clock synchronously sampled at multiple sampling times within the current update cycle, and fit a linear model of the time difference corresponding to the current update cycle changing with the value of the hardware clock based on the multiple sampling times and their corresponding time difference sequences.

[0051] In this embodiment, a sampling window can be set, the length of which determines the number of sampling moments within the window. The sampling window slides with the update cycle to periodically update the linear model of the time difference changing over time. The physical network card driver can determine the sliding step size of the sampling window according to the set update cycle. Update cycle = sliding step size * sampling cycle. The physical network card driver can slide the sampling window on the time axis according to this sliding step size, and after each sliding of the sampling window, it re-performs linear fitting based on the multiple sampling moments within the sampling window and their corresponding difference sequences to continuously update the linear model of the time difference changing with the hardware clock value. The length of the update cycle can be selected according to requirements; the smaller the update cycle, the faster the time difference calculation model can track changes in the frequency offset rate.

[0052] In this embodiment, it can be assumed that the difference between the hardware clock and the software clock varies with time under the influence of the frequency offset rate, and the following time difference calculation model can be established: in This is the value of the physical network card's hardware clock. Among them, It is the initial difference between the virtual machine's software clock and hardware clock at the initial sampling time. This indicates the frequency offset between the hardware clock and the software clock.

[0053] At the start of each update cycle, the physical network card driver can obtain the sequence values ​​of the software clock and the hardware clock according to the sampling window length N. The software clock sequence value and the hardware clock sequence value are obtained by synchronously sampling the software clock and the hardware clock according to a set sampling period T. The sampling window contains N sampling moments, and the value of N can be 40, 60, or other optional values; this embodiment does not impose any restrictions. Within the sampling window, the difference between the sequence values ​​of the software clock and the hardware clock can be calculated based on the alignment relationship of the sampling moments, resulting in a sequence of differences corresponding to multiple sampling moments. Optionally, within any sampling window, if the difference at a certain sampling moment... If the value exceeds a preset threshold, it can be considered that noise or scheduling jitter has occurred at that sampling moment, and the data at that sampling point can be temporarily discarded. At the arrival of any current update cycle, the physical network card driver can perform linear fitting based on multiple sampling moments within the sampling window of the current update cycle and their corresponding difference sequences to obtain the initial difference. and frequency offset The value of is used to fit a linear model of the time difference changing over time corresponding to the current update cycle.

[0054] After obtaining a linear model of the time difference as a function of the hardware clock within the current update cycle based on the above implementation method, the physical network card driver can predict the latest time difference between the physical network card and the virtual machine's software clock according to this linear model. For example, after receiving the first data packet, the original hardware receive timestamp is input into the linear model of the time difference as a function of the hardware clock to obtain the latest time difference corresponding to the original hardware receive timestamp.

[0055] Optionally, the physical network card driver can also periodically calculate the residual between the time difference output by the model and the actual measured time difference, and can dynamically adjust the length of the sampling window according to the error range to which the residual belongs, which will not be elaborated further.

[0056] Based on this implementation, a linear model of the time difference changing with the hardware clock value can be fitted using the difference sequence corresponding to multiple sampling times in each update cycle. This helps to reduce the impact of noise in a single acquisition, thereby perceiving the real slow drift and more accurately capturing the time difference between the physical network card's hardware clock and the virtual machine's software clock. It also enables the physical network card driver to predict the latest time difference corresponding to any moment of the hardware clock in real time based on the linear model.

[0057] The foregoing embodiments describe optional implementations whereby the physical network interface card (NIC) driver adjusts the hardware receive timestamp of the physical NIC along the data packet receiving path. In some exemplary embodiments, the physical NIC driver may also adjust the hardware send timestamp of the physical NIC along the data packet sending path. Exemplary descriptions will follow.

[0058] Optionally, the physical network interface card (NIC) driver can receive a second data packet sent by a second virtual machine. The second virtual machine can be any virtual machine running on the physical machine; it can be the same as or different from the first virtual machine, and this embodiment does not impose any restrictions. The physical NIC driver can add a software transmission timestamp to the second data packet based on the software clock of the second virtual machine. The physical NIC driver can forward this second data packet to the physical NIC, so that the physical NIC sends the second data packet to the destination and returns a notification message indicating completion of transmission. This notification message includes the original hardware transmission timestamp added by the physical NIC when sending the second data packet. This original hardware transmission timestamp is added by the physical NIC based on the value of its hardware clock. The physical NIC driver can adjust the original hardware transmission timestamp based on the time difference between the physical NIC's hardware clock and the software clock of the second virtual machine to obtain a corrected hardware transmission timestamp. The method for obtaining the time difference between the physical NIC's hardware clock and the software clock of the second virtual machine can be found in the description of the foregoing embodiments, and will not be repeated here.

[0059] The physical network interface card (NIC) driver can add a corrected hardware transmission timestamp to the NIC's transmission completion queue, allowing the target application in the second virtual machine's operating system to read the corrected hardware transmission timestamp from this queue via a specified interface. The corrected hardware transmission timestamp is used to compare with the software transmission timestamp to analyze processing delay points along the transmission path of the second data packet. Figure 2 As shown, after receiving the second data packet sent by the target application, the physical network card driver can send the second data packet to the external network through the physical network card and obtain the original hardware transmission timestamp added by the physical network card to the second data packet. The physical network card driver can correct the original hardware transmission timestamp to obtain the corrected hardware transmission timestamp, and return the corrected hardware transmission timestamp to the target application.

[0060] Based on this implementation, the physical network interface card (NIC) driver can adjust the hardware transmission timestamp added to data packets by the physical NIC according to the dynamically tracked time difference between the virtual machine's software clock and the physical NIC's hardware clock. This accurately maps the hardware transmission timestamp to the time domain of the virtual machine's software clock, effectively compensating for accumulated errors caused by clock drift between the physical NIC and the virtual machine. Therefore, on the data transmission path, the hardware time of the physical NIC and the software time of the virtual machine can be aligned at a lower cost without relying on the PTP protocol for clock calibration, facilitating accurate analysis of latency points on the data packet transmission path within the same time domain.

[0061] In addition to the physical network card time synchronization method provided in the foregoing embodiments, this application also provides a transmission delay analysis method. Figure 3 This is a flowchart illustrating a transmission delay analysis method provided in an exemplary embodiment of this application, as shown below. Figure 3 As shown, the method includes: Step 301: Obtain the software receive timestamp and the corrected hardware receive timestamp of the first data packet pointing to the first virtual machine. The software receive timestamp is added by the physical network card driver on the physical machine according to the software clock of the first virtual machine when the first data packet is received. The corrected hardware receive timestamp is obtained by the physical network card driver mapping the original hardware receive timestamp to the time domain corresponding to the software clock based on the latest time difference between the dynamically tracked software clock of the first virtual machine and the hardware clock of the physical network card. The original hardware receive timestamp is added by the physical network card when the first data packet is received.

[0062] Step 302: Analyze the processing delay points on the receiving path of the first data packet based on the software receiving timestamp and the hardware receiving timestamp.

[0063] This embodiment can be executed by a target application within the operating system of a virtual machine, which can be any virtual machine running on a physical machine. The virtual machine transmits data to the external network through the physical network card driver and the physical network card on the physical machine. In this embodiment, different reception timestamps of the first data packet are located in the same time domain. The target application can analyze the processing delay points on the reception path of the first data packet by comparing the reception timestamps of the first data packet.

[0064] In step 301, the generation methods of the software reception timestamp and the corrected hardware reception timestamp of the first data packet can be referred to the descriptions in the foregoing embodiments, and will not be repeated here. The target application can obtain the software reception timestamp and the corrected hardware reception timestamp by parsing the first data packet.

[0065] In step 302, the target application can analyze the processing delay point on the reception path of the first data packet based on the software reception timestamp and the corrected hardware reception timestamp. Optionally, the target application can calculate the physical network card driver's reception processing delay based on the difference between the software reception timestamp and the corrected hardware reception timestamp. That is, the physical network card driver's reception processing delay = software reception timestamp - corrected hardware reception timestamp. If the physical network card driver's reception processing delay is less than a set first threshold, it can be considered that the physical network card and the physical network card driver are in normal working condition, the first data packet can be processed in a timely manner, and the delay point on the reception path of the first data packet is not located in the link from receiving the first data packet from the network card hardware to handing it over to the physical network card driver. The target application can further analyze the upper layers of the kernel protocol stack to determine the processing delay point on the reception path. If the physical network card driver's reception processing delay is greater than a set second threshold, it means that the first data packet waited in the physical network card's reception queue for a long time before being sent by the physical network card driver. Therefore, it can be considered that the processing delay point on the reception path of the first data packet is located in the physical network card driver or the kernel's software interrupt handling link. In this embodiment, the second threshold is greater than the first threshold. The first threshold can be a value in the microsecond range, and the second threshold can be a value in the millisecond range; this embodiment does not impose any restrictions. For example, the second threshold can be set to 100 microseconds, and the second threshold can be set to 1 millisecond.

[0066] In this implementation, the corrected hardware receive timestamp and software receive timestamp of the first data packet acquired by the target application are located in the same time domain, allowing for accurate analysis of processing latency points along the data packet reception path. The corrected hardware receive timestamp is obtained by the physical network card driver adjusting the hardware receive timestamp added to the data packet by the physical network card based on the time difference between the dynamically tracked virtual machine's software clock and the physical network card's hardware clock. This timestamp adjustment method does not rely on the PTP protocol for clock calibration, resulting in lower costs and effectively reducing the dependence of network diagnostics on the PTP protocol. Even if a large number of virtual machines (tenants) in a cloud computing environment do not deploy the PTP protocol, accurate network latency analysis and performance observation can still be performed.

[0067] In some optional embodiments, the target application can also analyze the processing delay points on the data packet transmission path based on the transmission timestamps located in the same time domain.

[0068] Optionally, the target application can obtain a software transmission timestamp added by the operating system of the first virtual machine when sending the second data packet. This software transmission timestamp is added to a specified structure of the second data packet, and the target application can obtain it by parsing the structure of the second data packet. The target application can read the corrected hardware transmission timestamp of the second data packet from the completion queue of the physical network card through a specified interface. The corrected hardware transmission timestamp is obtained by the physical network card driver mapping the original hardware transmission timestamp to the time domain corresponding to the software clock based on the time difference between the physical network card and the operating system. The original hardware transmission timestamp is added by the physical network card when sending the second data packet. The target application can analyze the processing delay points on the transmission path of the second data packet based on the software reception timestamp and the corrected hardware transmission timestamp.

[0069] Optionally, the target application can calculate the difference between the corrected hardware transmission timestamp and the software transmission timestamp to obtain the transmission processing delay, where the transmission processing delay = corrected hardware transmission timestamp - software transmission timestamp. If the transmission processing delay is less than the set third threshold, it means that after the physical network card driver adds the data packet to the physical network card's transmission queue, the physical network card can send the data packet to the external network in a timely manner. Therefore, the processing delay point on the transmission path of the second data packet is not on the physical network card, and the target application can further analyze whether there is a transmission blocking problem in the kernel protocol stack. If the transmission processing delay is greater than the set fourth threshold, it means that the physical network card driver has added the data packet to the physical network card's transmission queue, but the physical network card cannot send the data packet to the external network in a timely manner. Therefore, the processing delay point on the transmission path of the second data packet may be located on the physical network card or the physical link, which will not be elaborated further. The fourth threshold is greater than the third threshold. For example, the third threshold can be a value in the microsecond range, and the fourth threshold can be set to a value in the millisecond range. This embodiment does not impose any restrictions.

[0070] In this implementation, the corrected hardware transmission timestamp and software transmission timestamp of the second data packet obtained by the target application are located in the same time domain, allowing for accurate analysis of processing latency points along the data packet transmission path. The corrected hardware transmission timestamp is obtained by the physical network card driver adjusting the hardware transmission timestamp added to the data packet by the physical network card based on the time difference between the dynamically tracked virtual machine's software clock and the physical network card's hardware clock. This timestamp adjustment method does not rely on the PTP protocol for clock calibration, resulting in lower costs and effectively reducing the network diagnostics' dependence on the PTP protocol. Even if a large number of virtual machines (tenants) in a cloud computing environment do not deploy the PTP protocol, accurate network latency analysis and performance observation can still be performed.

[0071] It should be noted that the execution subject of each step of the method provided in the above embodiments can be the same device, or the method can be executed by different devices. For example, the execution subject of steps 101 to 104 can be device A; or the execution subject of steps 101 and 102 can be device A, and the execution subject of step 103 can be device B; and so on.

[0072] Furthermore, some processes described in the above embodiments and accompanying drawings include multiple operations appearing in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 101, 102, etc., are merely used to distinguish different operations and do not represent any execution order. Additionally, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that the descriptions such as "first" and "second" in this document are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

[0073] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0074] Figure 4 This application illustrates a schematic diagram of the structure of an electronic device provided in an exemplary embodiment, as shown below. Figure 4 As shown, the electronic device includes: a memory 401, a processor 402, and a communication component 403.

[0075] An electronic device acts as a host machine, running at least one virtual machine. The electronic device has a physical network card installed, and the physical network card driver is located between the physical network card of the physical machine and the operating system of the at least one virtual machine.

[0076] Memory 401 is used to store computer programs and can be configured to store various other data to support operation on the electronic device. Examples of this data include instructions for any application or method used to operate on the electronic device, data structures, contact data, phone book data, messages, pictures, videos, etc.

[0077] In some optional embodiments, the computer program stored in memory 401 is a physical network interface card (NIC) driver. Processor 402, coupled to memory 401, is configured to execute the computer program in memory 401 to: receive a first data packet sent by the physical NIC, the first data packet carrying an original hardware receive timestamp added by the physical NIC, the first data packet pointing to a first virtual machine; map the original hardware receive timestamp to the time domain corresponding to the software clock based on the latest time difference between the dynamically tracked software clock of the first virtual machine and the hardware clock of the physical NIC, obtaining a corrected hardware receive timestamp; add a software receive timestamp to the first data packet according to the software clock of the first virtual machine, and send the first data packet to the first virtual machine; provide the corrected hardware timestamp to the first virtual machine so that a target application on the first virtual machine can analyze the processing delay points on the reception path of the first data packet based on the software receive timestamp and the corrected hardware receive timestamp.

[0078] Optionally, the processor 402 is further configured to: synchronously collect the value of the hardware clock of the physical network card and the value of the software clock of the at least one virtual machine according to a set sampling period; and determine the latest time difference between the software clock of the at least one virtual machine and the hardware clock of the physical network card according to a set update period based on the synchronously collected values ​​of the hardware clock of the physical network card and the software clock of the at least one virtual machine.

[0079] Optionally, the update cycle is the same as the sampling cycle and is synchronized in time; when the processor 402 determines the latest time difference between the software clock of the at least one virtual machine and the hardware clock of the physical network card according to the set update cycle and the hardware clock of the physical network card and the software clock of the at least one virtual machine, it is specifically used to: for any virtual machine among the at least one virtual machine, when any current update cycle arrives, determine the time difference corresponding to the current update cycle according to the value of the hardware clock and the value of the software clock sampled synchronously in the current update cycle, and use it as the latest time difference between the software clock of the virtual machine and the hardware clock of the physical network card.

[0080] Optionally, when the processor 402 determines the latest time difference between the software clock of the at least one virtual machine and the hardware clock of the physical network card according to a set update cycle and based on the synchronously collected hardware clock value of the physical network card and the software clock value of the at least one virtual machine, it specifically performs the following: for any virtual machine among the at least one virtual machine, at the arrival of any current update cycle, it calculates the time difference sequence corresponding to the multiple sampling times based on the sequence values ​​of the hardware clock and the sequence values ​​of the software clock synchronously sampled at multiple sampling times in the current update cycle; based on the multiple sampling times and their corresponding time difference sequences, it fits a linear model of the time difference corresponding to the current update cycle changing with the value of the hardware clock; and based on the linear model of the time difference changing with the value of the hardware clock, it predicts the latest time difference between the software clock of the virtual machine and the hardware clock of the physical network card.

[0081] Optionally, the processor 402 is further configured to: receive a second data packet sent by a second virtual machine; add a software transmission timestamp to the second data packet according to the software clock of the second virtual machine; forward the second data packet to the physical network interface card (NIC) so that the NIC sends the second data packet to the destination and returns a notification message indicating completion of transmission, the notification message containing the original hardware transmission timestamp added by the NIC when sending the second data packet; map the original hardware transmission timestamp to the time domain corresponding to the software clock according to the latest time difference between the software clock of the second virtual machine and the hardware clock of the NIC, to obtain a corrected hardware transmission timestamp; add the corrected hardware transmission timestamp to the transmission completion queue of the NIC so that a target application in the operating system of the second virtual machine reads the corrected hardware transmission timestamp from the completion queue through a specified interface, the corrected hardware transmission timestamp being used to compare with the software transmission timestamp to analyze the processing delay points on the transmission path of the second data packet.

[0082] Optionally, the processor 402 is further configured to: add the corrected hardware receive timestamp to a target data structure in the kernel of the first virtual machine, so that a target application in the first virtual machine reads the corrected hardware receive timestamp from the target data structure and analyzes the processing delay point on the reception path of the first data packet based on the corrected hardware receive timestamp and the software receive timestamp.

[0083] Optionally, when the computer program stored in memory 401 is a physical network card driver, processor 402, coupled to memory 401, executes the computer program in memory 401 to: receive data packets sent by any virtual machine; add a software sending timestamp to the data packet according to the software clock of the virtual machine; forward the data packet to the physical network card so that the physical network card sends the data packet to the destination and returns a notification message indicating completion of transmission, the notification message containing the original hardware sending timestamp added by the physical network card when sending the data packet; map the original hardware sending timestamp to the time domain corresponding to the software clock according to the latest time difference between the hardware clock of the physical network card and the software clock of the virtual machine to obtain a corrected hardware sending timestamp; add the corrected hardware sending timestamp to the transmission completion queue of the physical network card so that a target application in the operating system of the virtual machine reads the corrected hardware sending timestamp from the completion queue through a specified interface, the corrected hardware sending timestamp being compared with the software sending timestamp to analyze the processing delay points on the transmission path of the data packet.

[0084] In some alternative embodiments, the computer program stored in memory 401 is a target application in any virtual machine that is used to analyze processing delay points on the transmission path of data packets.

[0085] Processor 402, coupled to memory 401, is used to execute a computer program in memory 401 for: acquiring a software receive timestamp and a corrected hardware receive timestamp of a first data packet pointing to a first virtual machine, wherein the software receive timestamp is added by the physical network card driver on the physical machine according to the software clock of the first virtual machine when the first data packet is received; the corrected hardware receive timestamp is obtained by the physical network card driver mapping the original hardware receive timestamp to the time domain corresponding to the software clock based on the latest time difference between the dynamically tracked software clock of the first virtual machine and the hardware clock of the physical network card, wherein the original hardware receive timestamp is added by the physical network card when the first data packet is received; and analyzing the processing delay points on the reception path of the first data packet based on the software receive timestamp and the hardware receive timestamp.

[0086] Optionally, the processor 402 is further configured to: obtain a software transmission timestamp added by the operating system of the first virtual machine when sending the first data packet; read the corrected hardware transmission timestamp of the first data packet from the completion queue of the physical network card through a specified interface, wherein the corrected hardware transmission timestamp is obtained by the physical network card driver mapping the original hardware transmission timestamp to the time domain corresponding to the software clock based on the latest time difference between the software clock of the first virtual machine and the hardware clock of the physical network card, wherein the original hardware transmission timestamp is added by the physical network card when sending the first data packet; and analyze the processing delay points on the transmission path of the first data packet based on the software reception timestamp and the corrected hardware transmission timestamp.

[0087] Furthermore, such as Figure 4 As shown, the electronic device also includes other components such as a power supply component 404, a display component 405, and an audio component 406. Figure 4 The diagram only shows some components and does not mean that the electronic device includes only these components. Figure 4 The components shown. Figure 4 In this embodiment, the components within the dashed boxes are optional, not mandatory, and their specific requirements depend on the product form of the electronic device. The electronic device in this embodiment can be a terminal device such as a desktop computer, laptop computer, smartphone, or IoT device, or a server-side device such as a conventional server, cloud server, or server array. If the electronic device in this embodiment is a terminal device such as a desktop computer, laptop computer, or smartphone, it may include... Figure 4 The components within the dashed box; if the electronic device in this embodiment is implemented as a conventional server, cloud server, or server array, it may be omitted. Figure 4 The component within the dashed box.

[0088] The memory 401 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random-access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0089] The communication component 403 is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access wireless networks based on communication standards, such as 2G (e.g., Global System for Mobile Communications (GSM)), 3G (e.g., Wideband Code Division Multiple Access (WCDMA), 4G (e.g., Long Term Evolution (LTE)), 4G+ (e.g., LTE-Advanced (LTE-A)), or 5G (5th Generation Mobile Communication Technology), or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel.

[0090] The power supply component 404 is used to provide power to various components of the device in which the power supply component is located. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which the power supply component is located.

[0091] The display component includes a screen, which may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen can be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors can sense not only the boundaries of the touch or swipe action but also the duration and pressure associated with the touch or swipe operation.

[0092] An audio component may be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals may be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0093] In this embodiment, the physical network interface card (NIC) driver can adjust the hardware receive timestamp or hardware send timestamp added to data packets by the physical NIC based on the time difference between the dynamically tracked virtual machine's software clock and the physical NIC's hardware clock. This accurately maps the hardware receive timestamp to the time domain of the virtual machine's software clock, effectively compensating for accumulated errors caused by clock drift between the physical NIC and the virtual machine. Therefore, on the data reception path, the hardware time of the physical NIC and the software time of the virtual machine can be aligned at a lower cost without relying on the PTP protocol for clock calibration, facilitating accurate analysis of processing latency points on the data packet transmission path within the same time domain. On the one hand, by reducing the reliance of network diagnostics on the PTP protocol, even if a large number of virtual machines (tenants) in the cloud computing environment do not deploy the PTP protocol, accurate network latency analysis and performance observation can still be performed. On the other hand, virtual machines (tenants) on a physical machine share the same physical network interface card (NIC). The physical clock of this NIC is a globally unified time reference source that is independent of the virtual machine (tenant). The physical NIC driver can achieve time domain synchronization by maintaining the time difference between the physical clock and the software clock of the virtual machine (tenant). This eliminates the need to rely on PTP hardware to allocate independent hardware PTP resources (such as dedicated timers or on-chip storage resources) for each virtual machine (tenant), which greatly reduces hardware overhead and effectively improves the elastic scalability and resource utilization of the cloud computing platform.

[0094] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, enables the processor to implement the steps in the above-described method embodiments. The computer-readable storage medium includes volatile or non-volatile components, or a combination thereof, and can be removable or non-removable. Examples of computer-readable storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), flash memory or other memory technologies, CD-ROM, Digital Video Disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium.

[0095] Accordingly, this application also provides a computer program product, which includes a computer program or instructions that, when executed by a processor, enable the processor to implement the steps in the above method embodiments.

[0096] This application also provides a physical machine on which at least one virtual machine runs. The physical network card driver on the physical machine is located between the physical network card of the physical machine and the operating system of the at least one virtual machine. The physical network card driver is used to execute the physical network card time synchronization method provided in this application, and the target application running on any of the at least one virtual machine is used to execute the transmission delay analysis method provided in this application.

[0097] This application also provides a computer cluster, which includes at least one physical machine provided in this application.

[0098] It should be understood that each or a combination of the above-described method flow can be implemented by computer programs or instructions. Furthermore, these computer programs or instructions can be applied to the processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device, enabling the processor of the general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to function as an apparatus for implementing the corresponding functions in the above-described method embodiments.

[0099] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, product, or apparatus that includes said element.

[0100] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for synchronizing the time of a physical network interface card (NIC), characterized in that, A physical network interface card (NIC) driver applied to a physical machine, wherein at least one virtual machine runs on the physical machine, and the physical NIC driver is located between the physical NIC of the physical machine and the operating system of the at least one virtual machine; the method includes: Receive a first data packet sent by the physical network card, the first data packet carrying the original hardware receive timestamp added by the physical network card, and the first data packet pointing to the first virtual machine; Based on the latest time difference between the software clock of the first virtual machine and the hardware clock of the physical network card, the original hardware receiving timestamp is mapped to the time domain corresponding to the software clock to obtain the corrected hardware receiving timestamp. Add a software reception timestamp to the first data packet according to the software clock of the first virtual machine, and send the first data packet to the first virtual machine; Providing the corrected hardware timestamp to the first virtual machine so that the target application on the first virtual machine can analyze the processing delay point on the reception path of the first data packet based on the software reception timestamp and the corrected hardware reception timestamp includes: calculating the reception processing delay of the physical network card driver based on the difference between the software reception timestamp and the corrected hardware reception timestamp; if the reception processing delay is less than a set first threshold, determining that the delay point on the reception path of the first data packet is not located in the stage from receiving the first data packet from the network card hardware to handing it over to the physical network card driver, and further analyzing the upper layer of the kernel protocol stack to determine the processing delay point on the reception path; if the reception processing delay is greater than a set second threshold, determining that the processing delay point on the reception path of the first data packet is located in the soft interrupt handling stage of the physical network card driver or the kernel; wherein, the second threshold is greater than the first threshold; The above methods also include: According to the set sampling period, the value of the hardware clock of the physical network card and the value of the software clock of the at least one virtual machine are collected synchronously. For any virtual machine among the at least one virtual machine, when any current update cycle arrives, calculate the time difference sequence corresponding to the multiple sampling times based on the sequence values ​​of the hardware clock and the software clock synchronously sampled at multiple sampling times in the current update cycle; Based on the multiple sampling times and their corresponding time difference sequences, fit a linear model of how the time difference corresponding to the current update cycle changes with the value of the hardware clock; Based on a linear model of how the time difference changes with the value of the hardware clock, the latest time difference between the virtual machine's software clock and the physical network card's hardware clock is predicted.

2. The method according to claim 1, characterized in that, Providing the corrected hardware timestamp to the first virtual machine includes: The corrected hardware receive timestamp is added to a target data structure in the kernel of the first virtual machine so that the target application can read the corrected hardware receive timestamp from the target data structure.

3. The method according to claim 1, characterized in that, Also includes: Receive the second data packet sent by the second virtual machine; Based on the software clock of the second virtual machine, add a software sending timestamp to the second data packet; The second data packet is forwarded to the physical network interface card (NIC) so that the physical NIC sends the second data packet to the destination and returns a notification message indicating that the sending is complete. The notification message contains the original hardware sending timestamp added by the physical NIC when sending the second data packet. Based on the latest time difference between the software clock of the second virtual machine and the hardware clock of the physical network card, the original hardware transmission timestamp is mapped to the time domain corresponding to the software clock to obtain the corrected hardware transmission timestamp. The corrected hardware transmission timestamp is added to the transmission completion queue of the physical network card, so that the target application in the operating system of the second virtual machine can read the corrected hardware transmission timestamp from the completion queue through a specified interface. The corrected hardware transmission timestamp and the software transmission timestamp are used to analyze the processing delay points on the transmission path of the second data packet.

4. A method for synchronizing the time of a physical network interface card (NIC), characterized in that, A physical network interface card (NIC) driver applied to a physical machine, wherein at least one virtual machine runs on the physical machine, and the physical NIC driver is located between the physical NIC of the physical machine and the operating system of the at least one virtual machine; the method includes: Receive data packets sent by any virtual machine; Based on the software clock of the virtual machine, add a software sending timestamp to the data packet; The data packet is forwarded to the physical network interface card (NIC) so that the NIC sends the data packet to the destination and returns a notification message indicating that the sending is complete. The notification message contains the original hardware sending timestamp added by the NIC when sending the data packet. Based on the latest time difference between the virtual machine's software clock and the physical network card's hardware clock, the original hardware transmission timestamp is mapped to the time domain corresponding to the software clock to obtain the corrected hardware transmission timestamp. The corrected hardware transmission timestamp is added to the transmission completion queue of the physical network card so that the target application in the operating system of the virtual machine can read the corrected hardware transmission timestamp from the completion queue through a specified interface. The corrected hardware transmission timestamp and the software transmission timestamp are used to analyze the processing delay points on the transmission path of the data packet. The above methods also include: According to the set sampling period, the value of the hardware clock of the physical network card and the value of the software clock of the at least one virtual machine are collected synchronously. For any virtual machine among the at least one virtual machine, when any current update cycle arrives, calculate the time difference sequence corresponding to the multiple sampling times based on the sequence values ​​of the hardware clock and the software clock synchronously sampled at multiple sampling times in the current update cycle; Based on the multiple sampling times and their corresponding time difference sequences, fit a linear model of how the time difference corresponding to the current update cycle changes with the value of the hardware clock; Based on a linear model of how the time difference changes with the value of the hardware clock, predict the latest time difference between the virtual machine's software clock and the physical network card's hardware clock. Specifically, when the target application analyzes the processing delay point on the transmission path of the data packet, it calculates the difference between the corrected hardware transmission timestamp and the software transmission timestamp to obtain the transmission processing delay; if the transmission processing delay is less than a set third threshold, it determines that the processing delay point on the transmission path of the data packet is not on the physical network card, and further analyzes whether there is a transmission blocking problem in the kernel protocol stack; if the transmission processing delay is greater than a set fourth threshold, it determines that the processing delay point on the transmission path of the data packet is located on the physical network card or physical link, wherein the fourth threshold is greater than the third threshold.

5. A method for analyzing transmission delay, characterized in that, A target application applied to an operating system of a virtual machine, wherein the virtual machine is any virtual machine running on a physical machine; the virtual machine transmits data with an external network through the physical network card driver and the physical network card on the physical machine; the method includes: The software receive timestamp and the corrected hardware receive timestamp of the first data packet pointing to the first virtual machine are obtained. The software receive timestamp is added by the physical network card driver on the physical machine according to the software clock of the first virtual machine when the first data packet is received. The corrected hardware receive timestamp is obtained by the physical network card driver mapping the original hardware receive timestamp to the time domain corresponding to the software clock based on the latest time difference between the software clock of the first virtual machine and the hardware clock of the physical network card, which is dynamically tracked. The original hardware receive timestamp is added by the physical network card when the first data packet is received. Analyzing the processing delay point on the reception path of the first data packet based on the software reception timestamp and the hardware reception timestamp includes: calculating the reception processing delay of the physical network card driver based on the difference between the software reception timestamp and the corrected hardware reception timestamp; if the reception processing delay is less than a set first threshold, determining that the delay point on the reception path of the first data packet is not located in the stage from receiving the first data packet from the network card hardware to handing it over to the physical network card driver, and further analyzing the upper layer of the kernel protocol stack to determine the processing delay point on the reception path; if the reception processing delay is greater than a set second threshold, determining that the processing delay point on the reception path of the first data packet is located in the software interrupt handling stage of the physical network card driver or the kernel; wherein, the second threshold is greater than the first threshold; The physical network interface card (NIC) is further configured to: synchronously collect the value of the hardware clock of the physical NIC and the value of the software clock of at least one virtual machine according to a set sampling period; for any virtual machine among the at least one virtual machine, at the arrival of any current update period, calculate the time difference sequence corresponding to the multiple sampling times based on the sequence values ​​of the hardware clock and the sequence values ​​of the software clock synchronously sampled at multiple sampling times in the current update period; fit a linear model of the time difference corresponding to the current update period as the value of the hardware clock changes based on the multiple sampling times and their corresponding time difference sequences; and predict the latest time difference between the software clock of the virtual machine and the hardware clock of the physical NIC based on the linear model of the time difference as the value of the hardware clock changes.

6. The method according to claim 5, characterized in that, Also includes: Obtain the software sending timestamp added by the operating system of the first virtual machine when sending the first data packet; The corrected hardware transmission timestamp of the first data packet is read from the completion queue of the physical network card through a specified interface. The corrected hardware transmission timestamp is obtained by the physical network card driver by mapping the original hardware transmission timestamp to the time domain corresponding to the software clock based on the latest time difference between the software clock of the first virtual machine and the hardware clock of the physical network card. The original hardware transmission timestamp is added by the physical network card when it sends the first data packet. Based on the software receiving timestamp and the corrected hardware sending timestamp, analyze the processing delay points on the sending path of the first data packet.

7. A physical machine, characterized in that, At least one virtual machine runs on the physical machine, and the physical network card driver on the physical machine is located between the physical network card of the physical machine and the operating system of the at least one virtual machine; The physical network card driver is used to execute the method according to any one of claims 1-4, and the target application running on any one of the at least one virtual machines is used to execute the method according to claim 5 or 6.

8. A computer cluster, characterized in that, It includes at least one physical machine as described in claim 7.

9. An electronic device, characterized in that, include: Memory and processor; The memory is used to store one or more computer instructions; The processor is configured to execute one or more computer instructions for performing the steps of the method according to any one of claims 1-6.

10. A computer-readable storage medium storing a computer program, characterized in that, When a computer program is executed by a processor, it is able to perform the steps of the method described in any one of claims 1-6.

11. A computer program product, characterized in that, include: A computer program / instruction that, when executed by a processor, enables the implementation of the steps in the method described in any one of claims 1-6.

Images