Lightweight time synchronization method and performance monitoring method for data center network

Abstract

According to the lightweight time synchronization method and the performance monitoring method for the data center network, a request / response unicast communication mechanism is adopted, a slave clock initiates a time synchronization request actively, a master clock responds passively, and time synchronization is completed through data packet interaction, so that unicast negotiation is not needed, the time synchronization process is simplified, and the time synchronization efficiency is improved. The time synchronization protocol complexity is reduced, the network overhead and resource consumption are reduced, the time synchronization efficiency and reliability are further improved, convenient conditions are provided for data center network performance monitoring, the data center network performance monitoring capability is achieved, the master-slave clock synchronization performance is conveniently monitored, and the data center network performance monitoring efficiency is improved. Therefore, the technical problems that a traditional PTP time synchronization protocol is complex in protocol, low in efficiency, large in network overhead, insufficient in performance monitoring capacity and the like are solved, the time synchronization efficiency, reliability and precision are improved, and then the high-precision and high-reliability time synchronization requirements needed by a large data center network service system are met.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and more specifically, to a lightweight time synchronization method and performance monitoring method for data center networks. Background Technology

[0002] Data centers are typical distributed data processing systems, which are time-sensitive computing systems. Data operations such as control, computation, processing, and analysis between different computing devices within the system are time-sequential, with timestamps determining the order of events and operations. Time synchronization is fundamental to the collaborative operation of various systems within a data center network. If system times are inconsistent or synchronization accuracy is low, it may lead to data corruption, loss, or collisions in centralized arbitration and scheduling, thereby affecting the overall performance of the data center network and the normal operation of services.

[0003] PTP (Precision Time Protocol) is one of the mainstream technologies for high-precision network time synchronization. It uses hardware timestamps to improve time resolution, typically achieving network time synchronization accuracy from 100ns to 10us, which can meet the time synchronization needs of small data center networks. The PTP time synchronization protocol (IEEE 1588) defines two communication methods: multicast and unicast. Multicast communication is simpler to implement and configure than unicast, saving system resources of the master clock. However, multicast packets are prone to multicast storms and have high bandwidth consumption (due to switch replication and forwarding), making it generally unsuitable for data center network applications. Currently, time synchronization in ordinary data center networks mainly uses PTP unicast communication. Unicast communication is more reliable than multicast, but the PTP unicast negotiation mechanism is complex to implement, resulting in relatively lower synchronization efficiency.

[0004] The IEEE 1588v2 (PTP) standard defines unicast communication and the corresponding unicast negotiation mechanism. PTP master and slave clocks must first establish a connection through a unicast signaling negotiation mechanism before point-to-point unicast time synchronization can occur. The unicast negotiation mechanism requires the exchange of unicast TLV (type, length, value) signaling information between the PTP master and slave clocks. TLV signaling types used for unicast negotiation include unicast request transmission signaling (REQUEST_UNICAST_TRANSMISSION TLV), agree unicast request transmission signaling (GRANT_UNICAST_TRANSMISSION TLV), cancel unicast request transmission signaling (CANCEL_UNICAST_TRANSMISSION TLV), acknowledge cancel unicast transmission signaling (ACKNOWLEDGE_CANCEL_UNICAST_TRANSMISSION TLV), and enable unicast negotiation mechanism transmission signaling (UNICAST_NEGOTIATION_ENABLE TLV). Unicast message types include data packets such as Sync, Announce, Delay_resp, and Pdelay_resp. Each data packet requires negotiation. Only after successful negotiation can the normal time synchronization process begin; otherwise, time synchronization cannot be performed. Additionally, the PTP master and slave clocks need to periodically perform unicast negotiation. If a slave clock fails to re-initiate unicast negotiation within a specified time period, the master clock will refuse to process synchronization request packets from that slave clock and remove it from the client list.

[0005] PTP unicast negotiation mechanism, such as Figure 1 As shown, the slave clock sends a request, and the master clock responds to the request. Through a process of request -> agreement / disagreement -> confirmation, the unicast negotiation function for different data packets is realized.

[0006] A diagram illustrating the PTP time synchronization method is shown below. Figure 2As shown. The master clock periodically sends Sync messages to the slave clock. The Sync message carries a transmission timestamp T1; in two-step mode, the Follow_Up message carries timestamp T1. Upon receiving the Sync message, the slave clock generates a reception timestamp T2. The slave clock periodically sends Delay_Req messages to the master clock, storing the transmission timestamp T3 locally. Upon receiving the Delay_Req message, the master clock generates a reception timestamp T4 and returns it to the slave clock along with a Delay_Resp acknowledgment message. The master clock periodically sends Announce messages to the slave clock, carrying the master clock's status information. The slave clock calculates the average line delay and master-slave time deviation based on the obtained timestamps (T1, T2, T3, T4). The calculation method is as follows: Average one-way delay: [(T4-T1)-(T3-T2)] / 2.

[0007] Master-slave time deviation: [(T2-T1)-(T4-T3)] / 2.

[0008] The slave clock adjusts its local time using the calculated time deviation value to achieve master-slave clock time synchronization.

[0009] The traditional PTP unicast communication method described above has the following main drawbacks: (1) The unicast negotiation mechanism is complex and has low synchronization efficiency. The use of a complex unicast signaling negotiation mechanism results in low synchronization efficiency. There are many types of TLV signaling, and multiple steps such as request, reply (agree, reject), and confirmation are required to establish a unicast connection. Moreover, unicast negotiation needs to be performed periodically to maintain normal time synchronization.

[0010] (2) Complex implementation affects the load capacity of the device. Load capacity is an important indicator of the master clock device. The unicast negotiation mechanism is complex to implement and requires periodic sending and processing of unicast negotiation signaling, which increases the burden on the device processor and thus affects the load capacity and efficiency of the master clock device.

[0011] (3) Increased network overhead and impact on synchronization accuracy. The unicast TLV signaling frame is about 44 bytes long (frame header plus TLV information). The periodically sent unicast negotiation signaling will increase network overhead, occupy more bandwidth, and may cause packet delay variation (PDV), which will affect the master-slave clock synchronization accuracy.

[0012] (4) Insufficient performance monitoring capabilities. The PTP unicast negotiation mechanism does not consider performance monitoring functions at the protocol level, especially from the clock side, resulting in insufficient performance monitoring capabilities. Basic performance monitoring functions can be achieved from the clock by reporting performance monitoring TLV signaling, but this method requires additional bandwidth.

[0013] It is evident that traditional PTP time synchronization protocols (especially unicast mode) are relatively complex, inefficient, have high network overhead, and insufficient performance monitoring capabilities. They cannot fully adapt to and meet the high-precision and high-reliability time synchronization requirements of the ever-increasing network performance (data processing capabilities and efficiency) of large data centers. Summary of the Invention

[0014] This invention aims to provide a lightweight time synchronization method and performance monitoring method for data center networks, in order to solve the problem that the traditional PTP time synchronization protocol cannot adapt to and meet the high-precision and high-reliability time synchronization requirements of large data centers.

[0015] In a first aspect, the present invention provides a lightweight time synchronization method for data center networks, comprising: Step 1: Send a unicast delay request data packet Delay_Req from the clock to the master clock, and record the sending timestamp T3; the unicast delay request data packet Delay_Req carries management information; Step 2: The master clock receives the unicast delay request data packet Delay_Req sent by the slave clock, records the reception timestamp T4, parses the unicast delay request data packet Delay_Req, obtains the management information and correction field CorrectionField_1, and calculates the corrected reception timestamp T4_1 based on the reception timestamp T4 and the correction field CorrectionField_1. Step 3: The master clock sends a unicast synchronization data packet Sync to the slave clock and records the transmission timestamp T1; the unicast synchronization data packet Sync carries the transmission timestamp T1, the corrected reception timestamp T4_1, and management information; Step 4: The master clock sends a unicast status data packet Announce to the slave clock; the unicast status data packet Announce carries the status parameters of the master clock; Step 5: Receive the unicast synchronization data packet Sync sent by the master clock from the clock, record the received timestamp T2, parse the unicast synchronization data packet Sync, obtain the management information, timestamp T1, timestamp T4_1, correction field_2, and calculate the corrected received timestamp T2_1 based on the received timestamp T2 and the correction field_2. Step 6: Receive the unicast status data packet Announce sent by the master clock from the clock, parse the unicast status data packet Announce to obtain the status parameters of the master clock, and select the optimal master clock based on the status parameters of the master clock; Step 7: The slave clock calculates the master-slave clock time deviation Td based on the transmission timestamp T1, the corrected reception timestamp T2_1, the transmission timestamp T3, and the corrected reception timestamp T4_1, and adjusts the local system time to complete one time synchronization process; Step 8: The slave clock repeats steps 1 to 7 according to the set packet sending cycle, continuously adjusting the local system time, and finally achieving master-slave clock time synchronization.

[0016] In a preferred embodiment, the unicast state data packet Announce contains only clock state parameters in its data packet frame format.

[0017] In a preferred embodiment, the method for calculating the corrected reception timestamp T4_1 is as follows: T4_1 = T4 - CorrectionField_1; The CorrectionField_1 refers to the CorrectionField field in the frame header of the unicast delay request data packet Delay_Req, which is used to compensate for the dwell time of the transmission node.

[0018] In a preferred embodiment, the method for calculating the corrected receiving timestamp T2_1 is as follows: T2_1 = T2 - CorrectionField_2; The CorrectionField_2 refers to the CorrectionField field in the frame header of the unicast synchronization data packet Sync, which is used to compensate for the dwell time of the transmission node.

[0019] In a preferred embodiment, the unicast delay request data packet Delay_Req and the unicast synchronization data packet Sync also carry a transmission sequence number sequenceId. The slave clock checks whether the transmission sequence number sequenceId of the received unicast synchronization data packet Sync is consistent with the transmission sequence number sequenceId of the unicast delay request data packet Delay_Req sent by the slave clock. If they are inconsistent, it is determined that the unicast delay request data packet Delay_Req and the unicast synchronization data packet Sync do not match. If the unicast delay request data packet Delay_Req and the unicast synchronization data packet Sync do not match, the data packet for this synchronization is discarded, and the master-slave clock time deviation is not calculated.

[0020] In a preferred embodiment, the integer seconds of the corrected receive timestamp T4_1 are recovered from the clock using the timing relationship between the transmit timestamp T1 and the corrected receive timestamp T4_1: Let LSB_T4 be the least significant byte of the integer seconds of the corrected receive timestamp T4_1, and LSB_T1 be the least significant byte of the integer seconds of the transmission time difference T1, and T1 > T4_1; Comparing LSB_T4 and LSB_T1: If LSB_T4 equals LSB_T1, then the integer seconds of the received timestamp T4_1 are corrected to equal the integer seconds of the sent timestamp T1. Otherwise, the integer seconds of the received timestamp T4_1 are corrected to be equal to the integer seconds of the sent timestamp T1 minus 1.

[0021] In a preferred embodiment, the management information also includes validity flags, packet sending enablement, and packet sending cycle; The validity flag is used to verify the validity of data packets between the master and slave clocks. Data packets are only processed when the flag is valid; otherwise, the data packets are discarded. The packet sending enable is used to control whether to send the unicast status data packet Announce. When performing performance monitoring, the unicast status data packet Announce is not sent. The packet sending period is used to set the packet sending interval for unicast status data packets Announces.

[0022] In a preferred embodiment, the management information is transmitted using the reserved field in the frame header of the unicast delay request packet Delay_Req and the unicast synchronization packet Sync.

[0023] Secondly, the present invention provides a performance monitoring method for data center networks, which is based on the aforementioned lightweight time synchronization method for data center networks. The performance monitoring method for data center networks includes: The monitoring device runs the slave clock function of the lightweight time synchronization method, the server runs the master clock function of the lightweight time synchronization method, and the client runs both the slave clock and master clock functions of the lightweight time synchronization method. The client can function as both a slave clock and a master clock. When acting as a slave clock, it synchronizes time with the server. When acting as a master clock, it responds to the unicast delay request data packet Delay_Req sent by the monitoring device to perform performance monitoring. The server acts as the master clock, responding to the unicast delay request data packets Delay_Req sent by the client to achieve time synchronization; on the other hand, it responds to the unicast delay request data packets Delay_Req sent by the monitoring device to achieve performance monitoring. The monitoring equipment uses a polling method to send unicast delay request data packets Delay_Req to the monitored servers and / or clients in the system in sequence. The monitored servers and / or clients respond and reply with unicast synchronization data packets Sync. The unicast synchronization data packets Sync carry timestamps and management information. The monitoring equipment uses the lightweight time synchronization method to calculate and obtain the time deviation, thereby enabling performance monitoring of servers and / or clients within the system. The monitoring device controls whether the monitored server and / or client sends a unicast status data packet Announce through the management information in the unicast delay request data packet Delay_Req; if it is not necessary to monitor the clock status parameters of each server and / or client, the unicast status data packet Announce is not sent.

[0024] In a preferred embodiment, the monitoring device includes data analysis software that analyzes, compares, calculates, and evaluates time deviations to provide timely warnings when performance anomalies are detected.

[0025] In summary, this invention employs a request / response unicast communication mechanism, where the slave clock actively initiates a time synchronization request, and the master clock passively responds. Time synchronization is completed through data packet interaction, eliminating the need for unicast negotiation, simplifying the time synchronization process, reducing the complexity of the time synchronization protocol, decreasing network overhead and resource consumption, further improving time synchronization efficiency and reliability, and providing convenient conditions for data center network performance monitoring. This enables performance monitoring capabilities, facilitating the monitoring of master-slave clock synchronization performance, thereby solving the technical problems of traditional PTP time synchronization protocols such as protocol complexity, low efficiency, high network overhead, and insufficient performance monitoring capabilities. It improves time synchronization efficiency, reliability, and accuracy, ultimately meeting the high-precision, high-reliability time synchronization requirements of large data center network business systems. Specifically: 1. Simple protocol, easy to implement. Compared with the traditional PTP time synchronization method, the lightweight time synchronization method of this invention reduces the types of data packets and the number of interactions. Only one request (Delay_Req) ​​ / response (Sync) data packet interaction is needed to achieve the time synchronization function. The protocol is simpler and easier to implement.

[0026] 2. No unicast negotiation required, resulting in high synchronization efficiency. The lightweight time synchronization method of this invention adopts unicast communication, eliminating the complex unicast signaling negotiation mechanism in the traditional PTP time synchronization method. No unicast negotiation is required between the master and slave clocks, which simplifies the processing flow and greatly improves the time synchronization efficiency.

[0027] 3. Low network overhead and low resource consumption. The lightweight time synchronization method of this invention only involves unicast delay request packets Delay_Req, unicast synchronization packets Sync, and unicast status packets Announce. The size of the unicast status packet Announce is reduced by 40% compared to the PTP standard, making the time synchronization process simpler, reducing network overhead, and lowering master-slave clock resource consumption.

[0028] 4. High reliability due to clock-driven operation. The lightweight time synchronization method of this invention initiates the synchronization process proactively by the slave clock, while the master clock only needs to passively respond and reply. It also eliminates the need to maintain a slave clock list, reducing the implementation complexity of the master clock. Because the time synchronization process is simple and less complex, the reliability of time synchronization is higher.

[0029] 5. Flexible configuration and convenient performance monitoring. This invention utilizes reserved fields in data packets to transmit management information, achieving basic configuration and management functions without affecting the time synchronization process, changing the data packet frame format, or adding additional network overhead. Through flexible configuration, the master-slave clock synchronization performance can be easily monitored. Attached Figure Description

[0030] Figure 1 This is a schematic diagram of the PTP unicast negotiation mechanism.

[0031] Figure 2 This is a schematic diagram of the PTP time synchronization method.

[0032] Figure 3 This is a schematic diagram of the data packet frame format of the unicast delay request data packet Delay_Req and the unicast synchronization data packet Sync in an embodiment of the present invention.

[0033] Figure 4 This is a schematic diagram of the data packet frame format of the unicast state data packet Announce in an embodiment of the present invention.

[0034] Figure 5 This is a schematic diagram of a lightweight time synchronization method for data center networks provided in an embodiment of the present invention.

[0035] Figure 6 A flowchart illustrating a lightweight time synchronization method for data center networks provided in an embodiment of the present invention.

[0036] Figure 7 This is a schematic diagram of a performance monitoring method for data center networks provided in an embodiment of the present invention. Detailed Implementation

[0037] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0038] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0039] To address the issue that traditional PTP time synchronization protocols cannot adapt to and meet the high-precision, high-reliability time synchronization requirements of large data centers, this invention provides a lightweight time synchronization method for data center networks. This method employs a request / response unicast communication mechanism, where the slave clock actively initiates a time synchronization request, and the master clock passively responds, completing time synchronization through data packet exchange.

[0040] The data packets include a unicast delay request packet Delay_Req, a unicast synchronization packet Sync, and a unicast status packet Announce. The packet frame formats of the unicast delay request packet Delay_Req, the unicast synchronization packet Sync, and the unicast status packet Announce all conform to the IEEE 1588 (PTP) standard specification; specifically, the packet frame formats of the unicast delay request packet Delay_Req, the unicast synchronization packet Sync, and the unicast status packet Announce are as follows: Figure 3 As shown; the packet frame format of the unicast status data packet Announce needs to be optimized, such as... Figure 4 As shown, in this embodiment of the invention, unnecessary redundant information has been removed from the unicast state data packet Announce frame format, while clock state parameters are retained. This is to further reduce protocol complexity and network overhead. The size of the unicast state data packet Announce has been reduced from the standard-defined 64 bytes to 39 bytes, resulting in a 40% reduction in network overhead.

[0041] like Figure 5 , Figure 6 As shown, the lightweight time synchronization method for data center networks includes the following steps: Step 1: Send a unicast delay request data packet Delay_Req from the clock to the master clock, and record the sending timestamp T3 and the sending sequence number sequenceId; the unicast delay request data packet Delay_Req carries management information. In this embodiment of the invention, the management information includes validity flags, packet sending enable, packet sending cycle, etc.

[0042] Step 2: The master clock receives the unicast delay request data packet Delay_Req sent by the slave clock, records the reception timestamp T4, parses the unicast delay request data packet Delay_Req, obtains the management information, the transmission sequence number sequenceId, and the correction field CorrectionField_1, and calculates the corrected reception timestamp T4_1 based on the reception timestamp T4 and the correction field CorrectionField_1. The calculation method is: T4_1 = T4 - CorrectionField_1. The correction field CorrectionField_1 refers to the CorrectionField field in the frame header of the unicast delay request data packet Delay_Req, which is used to compensate for the dwell time of the transmission node.

[0043] In this embodiment of the invention, the master clock verifies the validity of the unicast delay request data packet Delay_Req through the validity flag in the management information. If the validity flag is 0, the unicast delay request data packet Delay_Req is discarded. If the validity flag is 1, the unicast delay request data packet Delay_Req is parsed and processed, and a unicast synchronization data packet Sync is replied.

[0044] Step 3: The master clock sends a unicast synchronization data packet Sync to the slave clock and records the sending timestamp T1; the unicast synchronization data packet Sync carries the sending timestamp T1, the corrected receiving timestamp T4_1, the sending sequence number sequenceId, and management information.

[0045] In this embodiment of the invention, the unicast synchronization data packet Sync adopts a one-step mode, and its sending timestamp T1 is inserted into the originTimestamp field of the unicast synchronization data packet Sync.

[0046] In this embodiment of the invention, the least significant byte (1 byte) of the integer seconds of the corrected received timestamp T4_1 is inserted into the reserved1 field (1 byte) of the unicast synchronization data packet Sync frame header, and the fractional seconds portion (4 bytes) of the corrected received timestamp T4_1 is inserted into the reserved2 field (4 bytes) of the unicast synchronization data packet Sync frame header.

[0047] The sequence number (sequenceId) in the unicast synchronization data packet Sync is the same as the sequence number (sequenceId) in the unicast delay request data packet Delay_Req. The purpose is to establish a matching relationship between the unicast delay request data packet Delay_Req and the unicast synchronization data packet Sync.

[0048] The management information carried in the unicast synchronization data packet Sync also includes validity flags, packet sending enable, packet sending cycle, etc.

[0049] Step 4: The master clock sends a unicast status data packet Announce to the slave clock; the unicast status data packet Announce carries the status parameters of the master clock.

[0050] The status parameters of the master clock are used to determine the optimal master clock from the slave clock, including grandmasterPriority1, grandmasterClockQuality, grandmasterPriority2, grandmasterIdentity, stepsRemoved, timeSource, etc. The status parameter definitions conform to the IEEE 1588 (PTP) standard specification.

[0051] Step 5: Receive the unicast synchronization data packet Sync sent by the master clock from the clock, record the received timestamp T2, parse the unicast synchronization data packet Sync, and obtain management information, timestamp T1, timestamp T4_1, correction field CorrectionField_2, and transmission sequence number sequenceId. Based on the received timestamp T2 and the correction field CorrectionField_2, calculate the corrected received timestamp T2_1 using the following calculation method: T2_1 = T2 - CorrectionField_2. The correction field CorrectionField_2 refers to the CorrectionField field in the frame header of the unicast synchronization data packet Sync, used to compensate for the dwell time of the transmission node.

[0052] In this embodiment of the invention, the clock verifies the validity of the unicast synchronization data packet Sync through the validity flag in the management information. If the validity flag is 0, the unicast synchronization data packet Sync is discarded; if the validity flag is 1, the unicast synchronization data packet Sync is parsed and processed.

[0053] In this embodiment of the invention, the sequence number (sequenceId) of the unicast synchronization data packet Sync received from the slave clock is checked to see if it matches the sequence number (sequenceId) of the unicast delay request data packet Delay_Req sent by the slave clock. If they do not match, it is determined that the unicast delay request data packet Delay_Req and the unicast synchronization data packet Sync do not match. If the unicast delay request data packet Delay_Req and the unicast synchronization data packet Sync do not match, the data packet for this synchronization is discarded, and the master-slave clock time deviation is not calculated.

[0054] In this embodiment of the invention, the integer seconds (4 bytes) of the corrected receive timestamp T4_1 are recovered from the clock using the timing relationship between the transmit timestamp T1 and the corrected receive timestamp T4_1. Since both the transmit timestamp T1 and the corrected receive timestamp T4_1 are generated by the master clock, and the corrected receive timestamp T4_1 has a fixed timing relationship with the transmit timestamp T1 (the transmit timestamp T1 lags behind the corrected receive timestamp T4_1), the complete integer seconds of the corrected receive timestamp T4_1 can be recovered using the least significant byte of the integer seconds. The specific method is as follows: (1) Let the least integer byte of the corrected receiving timestamp T4_1 be LSB_T4, the least integer byte of the sending time difference T1 be LSB_T1, and T1>T4_1; (2) Compare LSB_T4 with LSB_T1: If LSB_T4 equals LSB_T1, then the integer seconds of the received timestamp T4_1 are corrected to equal the integer seconds of the sent timestamp T1. Otherwise, the integer seconds of the received timestamp T4_1 are corrected to be equal to the integer seconds of the sent timestamp T1 minus 1.

[0055] Step 6: Receive the unicast status data packet "Announce" sent by the master clock from the clock, parse the unicast status data packet "Announce" to obtain the status parameters of the master clock, and select the optimal master clock based on the status parameters of the master clock. In this embodiment of the invention, the BMC algorithm is used to select the optimal master clock, and the BMC algorithm conforms to the IEEE 1588 (PTP) standard specification.

[0056] Step 7: The slave clock calculates the master-slave clock time deviation Td based on the transmission timestamp T1, the corrected reception timestamp T2_1, the transmission timestamp T3, and the corrected reception timestamp T4_1, and adjusts the local system time to complete one time synchronization process.

[0057] The method for calculating the master-slave clock time deviation Td is as follows: Td=[(T2_1-T1)-(T4_1-T3)] / 2.

[0058] Step 8: The slave clock repeats steps 1 to 7 according to the set packet sending cycle, continuously adjusting the local system time, and finally achieving master-slave clock time synchronization.

[0059] In the aforementioned lightweight time synchronization method for data center networks, the management information is transmitted using the reserved field in the frame header of the unicast delay request data packet Delay_Req and the unicast synchronization data packet Sync. This achieves basic management functions without affecting the time synchronization process, changing the data packet frame format, or adding additional network overhead, thereby improving the effectiveness, reliability, and efficiency of time synchronization.

[0060] The reserved domain is a data area not defined by the standard, such as... Figure 3 As shown, the reserved fields in the packet frame format of the unicast delay request packet Delay_Req and the unicast synchronization packet Sync include reserved (4 bits), reserved1 (1 byte), and reserved2 (4 bytes). Among them, the reserved1 and reserved2 fields have been used to carry the timestamps in the above method, so the reserved (4 bits) field is used to transmit management information.

[0061] The management information includes validity flags, packet sending enable, and packet sending cycle. The validity flag is used to verify the validity of data packets between the master and slave clocks; data packets are only processed when the flag is valid, otherwise they are discarded. Packet sending enable controls whether to send unicast status data packets (Announce). During performance monitoring, unicast status data packets (Announce) can be omitted, thus reducing network overhead. The packet sending cycle sets the interval between unicast status data packets (Announces). In the above method, unicast status data packets (Announce) are only used to transmit master clock status parameters. Since the master clock status parameters are relatively fixed, their sending frequency can be reduced, or they can be sent only when the clock status changes, further reducing network overhead without affecting the normal time synchronization process.

[0062] like Figure 3 As shown, the reserved field in the data packet frame header occupies 4 bits (b7, b6, b5, b4). In this embodiment of the invention, the 4-bit encoding is used to realize the above-mentioned management information transmission and interaction functions. The management information encoding and meaning are shown in Table 1.

[0063] Table 1. Management Information Codes and Their Meanings

[0064] As described above, the lightweight time synchronization method for data center networks provided by this invention optimizes and improves the traditional PTP time synchronization protocol. It adopts a request / response unicast communication mechanism, eliminating the need for unicast negotiation, simplifying the time synchronization process, reducing protocol complexity, network overhead, and resource consumption, and further improving time synchronization efficiency and reliability. Therefore, this method has advantages such as simple protocol, no need for unicast negotiation, low network overhead, slave clock driving, and low resource consumption. These advantages provide convenient conditions for data center network performance monitoring, enabling it to have performance monitoring capabilities and facilitating the monitoring of master-slave clock synchronization performance. Therefore, this invention also provides a performance monitoring method for data center networks, such as... Figure 7 As shown, the monitoring equipment, acting as a performance monitoring terminal, possesses an independent time reference signal and a high-precision time base. It employs a network-based remote monitoring method to centrally monitor the relative time deviation between the server and client within the system. Through flexible configuration, it can monitor both server and client performance. Specifically: (1) The monitoring device runs the slave clock function of the lightweight time synchronization method, the server runs the master clock function of the lightweight time synchronization method, and the client runs the slave clock and master clock functions of the lightweight time synchronization method.

[0065] (2) The client can function as both a slave clock and a master clock. When acting as a slave clock, it synchronizes time with the server. When acting as a master clock, it responds to the unicast delay request data packet Delay_Req sent by the monitoring device to perform performance monitoring.

[0066] (3) As the master clock, the server needs to respond to the unicast delay request data packet Delay_Req sent by the client to realize the time synchronization function, and also needs to respond to the unicast delay request data packet Delay_Req sent by the monitoring device to realize the performance monitoring function.

[0067] (4) The monitoring equipment uses a polling method to send unicast delay request data packets Delay_Req to the monitored server and / or client in the system in sequence. The monitored server and / or client respond and reply with unicast synchronization data packets Sync. The unicast synchronization data packets Sync carry timestamps and management information.

[0068] (5) The monitoring equipment uses the aforementioned lightweight time synchronization method to calculate and obtain the time deviation, thereby enabling performance monitoring of servers and / or clients within the system. The monitoring equipment includes data analysis software that analyzes, compares, calculates, and evaluates the time deviation to provide timely warnings when performance anomalies are detected, thus improving the reliability of time synchronization.

[0069] (6) The monitoring device controls whether the monitored server and / or client sends a unicast status data packet Announce through the management information in the unicast delay request data packet Delay_Req. If it is not necessary to monitor the clock status parameters of each server and / or client, the unicast status data packet Announce can be left unsent, thereby reducing network overhead.

[0070] As can be seen, the lightweight time synchronization method of the present invention has performance monitoring capabilities, which can facilitate the monitoring of master-slave clock synchronization performance. Therefore, in conjunction with the foregoing, the lightweight time synchronization method of the present invention can solve the technical problems of traditional PTP time synchronization protocols (especially unicast mode), such as protocol complexity, low efficiency, high network overhead, and insufficient performance monitoring capabilities, thereby improving time synchronization efficiency, reliability, and accuracy, and ultimately meeting the high-precision, high-reliability time synchronization requirements of large data center network service systems.

[0071] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A lightweight time synchronization method for data center networks, characterized in that, include: Step 1: Send a unicast delay request data packet Delay_Req from the clock to the master clock, and record the sending timestamp T3; The unicast delay request data packet Delay_Req carries management information; Step 2: The master clock receives the unicast delay request data packet Delay_Req sent by the slave clock, records the reception timestamp T4, parses the unicast delay request data packet Delay_Req, obtains the management information and correction field CorrectionField_1, and calculates the corrected reception timestamp T4_1 based on the reception timestamp T4 and the correction field CorrectionField_1. Step 3: The master clock sends a unicast synchronization data packet Sync to the slave clock and records the sending timestamp T1; The unicast synchronization data packet Sync carries a sending timestamp T1, a corrected receiving timestamp T4_1, and management information. Step 4: The master clock sends a unicast status data packet, Announce, to the slave clock; The unicast status data packet Announce carries the status parameters of the master clock. Step 5: Receive the unicast synchronization data packet Sync sent by the master clock from the clock, record the received timestamp T2, parse the unicast synchronization data packet Sync, obtain the management information, timestamp T1, timestamp T4_1, correction field_2, and calculate the corrected received timestamp T2_1 based on the received timestamp T2 and the correction field_2. Step 6: Receive the unicast status data packet Announce sent by the master clock from the clock, parse the unicast status data packet Announce to obtain the status parameters of the master clock, and select the optimal master clock based on the status parameters of the master clock; Step 7: The slave clock calculates the master-slave clock time deviation Td based on the transmission timestamp T1, the corrected reception timestamp T2_1, the transmission timestamp T3, and the corrected reception timestamp T4_1, and adjusts the local system time to complete one time synchronization process; Step 8: The slave clock repeats steps 1 to 7 according to the set packet sending cycle, continuously adjusting the local system time, and finally achieving master-slave clock time synchronization.

2. The lightweight time synchronization method for data center networks according to claim 1, characterized in that, The unicast status data packet Announce contains only clock status parameters in its data packet frame format.

3. The lightweight time synchronization method for data center networks according to claim 1, characterized in that, The method for calculating the corrected receiving timestamp T4_1 is as follows: T4_1 = T4 - CorrectionField_1; The CorrectionField_1 refers to the CorrectionField field in the frame header of the unicast delay request data packet Delay_Req, which is used to compensate for the dwell time of the transmission node.

4. The lightweight time synchronization method for data center networks according to claim 1, characterized in that, The method for calculating the corrected receiving timestamp T2_1 is as follows: T2_1 = T2 - CorrectionField_2; The CorrectionField_2 refers to the CorrectionField field in the frame header of the unicast synchronization data packet Sync, which is used to compensate for the dwell time of the transmission node.

5. The lightweight time synchronization method for data center networks according to claim 1, characterized in that, The unicast delay request data packet Delay_Req and the unicast synchronization data packet Sync also carry a transmission sequence number sequenceId; the clock checks whether the transmission sequence number sequenceId of the received unicast synchronization data packet Sync is consistent with the transmission sequence number sequenceId of the unicast delay request data packet Delay_Req sent by the clock. If they are inconsistent, it is determined that the unicast delay request data packet Delay_Req and the unicast synchronization data packet Sync do not match. If the unicast delay request packet Delay_Req and the unicast synchronization packet Sync do not match, the data packet for this synchronization is discarded, and the master-slave clock time deviation is not calculated.

6. The lightweight time synchronization method for data center networks according to claim 1, characterized in that, Recover the integer seconds of the corrected receive timestamp T4_1 from the clock using the timing relationship between the transmit timestamp T1 and the corrected receive timestamp T4_1: Let LSB_T4 be the least significant byte of the integer seconds of the corrected receive timestamp T4_1, and LSB_T1 be the least significant byte of the integer seconds of the transmission time difference T1, and T1 > T4_1; Comparing LSB_T4 and LSB_T1: If LSB_T4 equals LSB_T1, then the integer seconds of the received timestamp T4_1 are corrected to equal the integer seconds of the sent timestamp T1. Otherwise, the integer seconds of the received timestamp T4_1 are corrected to be equal to the integer seconds of the sent timestamp T1 minus 1.

7. The lightweight time synchronization method for data center networks according to claim 1, characterized in that, The management information also includes validity indicators, packet sending enablement, and packet sending cycle; The validity flag is used to verify the validity of data packets between the master and slave clocks. Data packets are only processed when the flag is valid; otherwise, the data packets are discarded. The packet sending enable is used to control whether to send the unicast status data packet Announce. When performing performance monitoring, the unicast status data packet Announce is not sent. The packet sending period is used to set the packet sending interval for unicast status data packets Announces.

8. The lightweight time synchronization method for data center networks according to claim 7, characterized in that, The management information is transmitted using the reserved field in the frame header of the unicast delay request packet Delay_Req and the unicast synchronization packet Sync.

9. A performance monitoring method for data center networks, characterized in that, The performance monitoring method for data center networks is implemented based on the lightweight time synchronization method for data center networks as described in any one of claims 1-8; The performance monitoring method for data center networks includes: The monitoring device runs the slave clock function of the lightweight time synchronization method, the server runs the master clock function of the lightweight time synchronization method, and the client runs both the slave clock and master clock functions of the lightweight time synchronization method. The client can function as both a slave clock and a master clock. When acting as a slave clock, it synchronizes time with the server. When acting as a master clock, it responds to the unicast delay request data packet Delay_Req sent by the monitoring device to perform performance monitoring. The server acts as the master clock, responding to the unicast delay request data packets Delay_Req sent by the client to achieve time synchronization; on the other hand, it responds to the unicast delay request data packets Delay_Req sent by the monitoring device to achieve performance monitoring. The monitoring equipment uses a polling method to send unicast delay request data packets Delay_Req to the monitored servers and / or clients in the system in sequence. The monitored servers and / or clients respond and reply with unicast synchronization data packets Sync. The unicast synchronization data packets Sync carry timestamps and management information. The monitoring equipment uses the lightweight time synchronization method to calculate and obtain the time deviation, thereby enabling performance monitoring of servers and / or clients within the system. The monitoring device controls whether the monitored server and / or client sends a unicast status data packet Announce through the management information in the unicast delay request data packet Delay_Req; if it is not necessary to monitor the clock status parameters of each server and / or client, the unicast status data packet Announce is not sent.

10. The performance monitoring method for data center networks according to claim 9, characterized in that, The monitoring equipment includes data analysis software that analyzes, compares, calculates, and evaluates time deviations to provide timely warnings when performance anomalies are detected.

Images