RTC clock skew test method under Linux operating system

Abstract

The invention relates to the technical field of computer application, and discloses an RTC clock skew test method under a Linux operating system, which comprises an RTC clock skew test step: firstly, determining a test type by judging whether a server to be tested is a local server or not; and if the server is a local server, acquiring local time and RTC time of a first time point, performing time synchronization through a pre-configured script, then acquiring RTC time and local time of a second time point, calculating an offset value, and generating a standard file display result. And if the server is a remote server, popping up a remote login information input window, establishing SSH connection after user input, executing the same test, obtaining an RTC time offset value, and generating a standard file. Therefore, the RTC clock skew test under the Linux operating system is realized.

Description

Technical Field

[0001] The present invention relates to the technical field of computer application, and in particular to a method for testing RTC clock offset under a Linux operating system. Background Art

[0002] RTC (Real-Time Clock) is a device that is independent of the system timer and is used to set the system clock, provide alarms or periodic timers. RTC can accurately track time and is not affected by device power failure, so it is an important part of many devices. RTC plays a key role in electronic products used in daily life, such as mobile phones, computers, watches and GPS in cars. Measuring RTC means testing and adjusting the real-time clock of the device to ensure that the device can accurately record time. In order to ensure the normal operation of systems and equipment, it is important to measure the accuracy of RTC regularly. Measuring and adjusting the accuracy of RTC can ensure the normal operation of equipment and systems, prevent data errors and information loss, and thus improve production efficiency and system stability. At present, the RTC clock offset test is mainly performed through the following two methods: checking the RTC time in the BIOS (Basic Input Output System) interface and comparing it with the Beijing time. After a period of time, without performing the RTC time synchronization operation, comparing it with the Beijing time again to measure the RTC clock offset value, requiring that the RTC clock offset does not exceed ±1.8 seconds per day (24 hours); or obtaining the RTC time through instructions under the OS (Operating System) and comparing it with the Beijing time. After a period of time, comparing it with the Beijing time again to check whether the RTC time offset value meets the requirement of not more than ±1.8 seconds per day (24 hours).

[0003] The existing RTC clock offset test methods often have the following technical problems:

[0004] First, the current RTC clock offset test checks the RTC time in the BIOS interface and compares it with Beijing time, using the naked eye to determine the offset. The same method is also used in the OS. This method relies on naked eye observation, resulting in large errors in the test data, thus affecting the accuracy of the test results.

[0005] Second, in the prior art, a uniform calibration interval, such as 24 hours, is usually used for different servers. This fixed solution cannot meet the personalized needs of different types of servers. In addition, the prior art lacks an effective RTC module fault analysis method, which makes it impossible to identify and solve potential problems in a timely manner.

[0006] Third, the application installation method in the prior art directly installs the application without first determining the time accuracy requirement of the program, ignoring the differences in the time accuracy requirements of applications, which may cause time errors during operation and affect application performance and data accuracy;

[0007] Fourth, in the prior art, before running the script on the server to be tested to perform the RTC clock offset test, the command differences between different Linux system distributions are not taken into account. Such differences may cause the script to fail to execute successfully in some distribution systems, thereby causing the test to fail. Summary of the invention

[0008] The summary of the invention is used to introduce concepts in a brief form, which will be described in detail in the detailed implementation section below. The summary of the invention is not intended to identify the key features or essential features of the technical solution claimed for protection, nor is it intended to limit the scope of the technical solution claimed for protection.

[0009] The present invention proposes a RTC clock offset testing method under a Linux operating system to solve one or more of the technical problems mentioned in the above background technology part.

[0010] The present invention provides a method for testing RTC clock offset under a Linux operating system, the method comprising:

[0011] Determine whether the server to be tested is a local server;

[0012] If the server to be tested is a local server, the RTC clock offset test step is executed: the local time of the server to be tested at the first time point is obtained, the local time at the first time point is determined as the first local time, and the first local time is synchronized with the Beijing time at the first time point through a pre-configured first script to obtain the synchronized first local time; the RTC time of the local server at the first time point is obtained, and the RTC time at the first time point is determined as the first RTC time; through the RTC time synchronization instruction provided by the Linux operating system and the pre-configured first script, the first RTC time is synchronized with the synchronized first local time to obtain the synchronized first RTC time; after the target time has passed, the RTC time of the local server at the second time point is determined as the second RTC time, and the local time of the local server at the second time point is determined as the second local time; through the local time synchronization instruction provided by the Linux operating system and the pre-configured first script, the second RTC time is synchronized to the second local time to obtain the synchronized second local time; through the pre-configured first script, a difference operation is performed on the synchronized second local time and the Beijing time at the second time point to obtain the calculation result of the difference operation, the calculation result is formed into a standard file, and the standard file is printed to the screen, and the calculation result is the RTC time offset value;

[0013] If the server to be tested is a remote server, the pre-configured second script is run, and a remote login information input window pops up to receive the remote login information entered by the user. According to the remote login information corresponding to the remote server, a secure shell protocol ssh connection is established with the remote server, and the RTC clock offset test step is executed to obtain the RTC time offset value of the remote server. The RTC time offset value is formed into a standard file, and the standard file is printed to the screen.

[0014] Optionally, a method for testing RTC clock offset under a Linux operating system of the present invention further includes: determining an offset level of a server to be tested according to an RTC time offset value; and querying a standard calibration interval duration corresponding to the offset level in a pre-configured calibration interval duration table according to the offset level;

[0015] Obtain the time accuracy requirement level of the server to be tested, determine the adjustment coefficient corresponding to the time accuracy requirement level, generate a target calibration interval duration according to the standard calibration interval duration and the adjustment coefficient, send the target calibration interval duration to the server to be tested, so that the server to be tested performs time calibration according to the target calibration interval duration, generate a calibration record and store the calibration record in a database, the calibration record includes a calibration time point and a calibration time difference;

[0016] A calibration record set within a target historical time period is obtained from a database, and a calibration time difference change trend corresponding to the target historical time period is calculated based on the calibration record set, where the calibration time difference change trend is stable or increasing; if the calibration time difference change trend is stable, first state information is generated to indicate that the offset of the server to be tested is in a stable state; if the calibration time difference change trend is increasing, second state information is generated to indicate that the offset of the server to be tested is in an unstable state, and based on the second state information, adjustment information for the target calibration interval duration or RTC module repair prompt information for the server to be tested is generated.

[0017] Optionally, a method for testing RTC clock offset under a Linux operating system of the present invention further includes: obtaining a pre-configured time accuracy query table, wherein the time accuracy query table includes multiple application categories and a time accuracy requirement sub-level corresponding to each application category;

[0018] The time accuracy requirement level of the server to be tested is determined as the benchmark time accuracy requirement level, and an application list of the server to be tested is determined, where the application list includes application names and application categories corresponding to the application names; the actual time accuracy requirement sub-level corresponding to each application name is queried from the time accuracy query table, and the actual time accuracy requirement sub-level is updated to the application list to obtain an updated application list; the updated application list, the time accuracy query table, and the benchmark time accuracy requirement level are all sent to the server to be tested, so that the server to be tested performs the following operations:

[0019] When a request to install a new application is detected, the application category of the new application is determined, and the time accuracy query table is queried based on the application category of the new application to obtain the actual time accuracy requirement sub-level corresponding to the new application. If the actual time accuracy requirement sub-level is lower than the benchmark time accuracy requirement level, the new application is allowed to be installed.

[0020] Optionally, a method for testing RTC clock offset under a Linux operating system of the present invention further includes: if the actual time accuracy requirement sub-level is higher than the benchmark time accuracy requirement level, time error risk warning information and a user command input control are displayed through a pop-up window, the time error risk warning information is used to prompt that there is a time error risk during the operation of a new application, and the user command input control is used to receive user commands input by the user in response to the time error risk warning information, and the user command indicates ignoring the risk or stopping the installation.

[0021] Optionally, a method for testing RTC clock offset under a Linux operating system of the present invention further includes: if the user instruction characterizes ignoring risk, determining the application name with the highest time accuracy requirement sub-level in the update application list as the benchmark application name, comparing the actual time accuracy requirement sub-level with the time accuracy requirement sub-level corresponding to the benchmark application name, and if the actual time accuracy requirement sub-level is less than or equal to the time accuracy requirement sub-level corresponding to the benchmark application name, allowing the new application to be installed.

[0022] The present invention has the following beneficial effects:

[0023] 1. The accuracy of the test results is improved by improving the RTC clock offset test method. Specifically, all times are synchronized at the beginning of the test, and any time synchronization operations are avoided during the test. At the end of the test, Beijing time is automatically obtained, and the obtained RTC time is synchronized to the local time of the server to calculate the difference between the two, thereby obtaining the RTC time offset value. The traditional method of directly calculating the difference between the RTC time and Beijing time may produce a large error, but by calculating the difference between the synchronized local time and Beijing time, the error can be significantly reduced. In addition, automatic acquisition of test time data is more efficient and accurate than manual acquisition, thereby improving the efficiency and accuracy of test data acquisition, avoiding error fluctuations caused by manual operations, and making test results more reliable;

[0024] 2. The calibration accuracy of the RTC clock and the health management capability of the module are significantly improved through personalized calibration interval settings for different servers and effective RTC module fault analysis methods. The calibration interval is dynamically adjusted according to the actual offset level and time accuracy requirements of the server to ensure that each server can maintain the best time accuracy in its specific environment. At the same time, combined with the trend analysis of the calibration records, potential faults of the RTC module can be identified in a timely manner to ensure stable operation of the system, thereby reducing the risk of data errors and information loss caused by time deviations and improving overall production efficiency and system reliability;

[0025] 3. By judging the time accuracy requirements of the application before installing it, only applications that meet the preset time accuracy requirements can be installed, thereby effectively reducing the impact of time errors on application performance and data accuracy. This method not only improves the overall time management capabilities of the system, but also enhances the compatibility between different applications, allowing the system to dynamically adjust the time accuracy standards according to actual needs, ensuring that various applications can stably and accurately calculate time during operation, thereby improving system efficiency;

[0026] 4. By identifying the command differences between different Linux distributions, the accuracy and reliability of the RTC clock offset test can be significantly improved, and the risk of test failure caused by command incompatibility can be reduced, thereby ensuring the validity and consistency of the test results. This method improves the stability of the RTC clock offset test script on different Linux system distributions and provides strong support for the precise management of system time. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] The above and other features, advantages and aspects of the embodiments of the present invention will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. Throughout the accompanying drawings, the same or similar reference numerals represent the same or similar elements. It should be understood that the drawings are schematic and that components and elements are not necessarily drawn to scale.

[0028] Figure 1 The present invention is a flow chart of a method for testing RTC clock offset under a Linux operating system. DETAILED DESCRIPTION

[0029] The present invention will be described in more detail below with reference to the accompanying drawings. Although certain embodiments of the present invention are shown in the accompanying drawings, it should be understood that the present invention can be implemented in various forms and should not be construed as being limited to the embodiments set forth herein. On the contrary, these embodiments are provided to provide a more thorough and complete understanding of the present invention. It should be understood that the drawings and embodiments of the present invention are only for exemplary purposes and are not intended to limit the scope of protection of the present invention.

[0030] It should also be noted that, for ease of description, only the parts related to the invention are shown in the drawings. In the absence of conflict, the embodiments of the present invention and the features in the embodiments can be combined with each other.

[0031] It should be noted that the concepts such as "first" and "second" mentioned in the present invention are only used to distinguish different devices, modules or units, and are not used to limit the order or interdependence of the functions performed by these devices, modules or units.

[0032] It should be noted that the modifications of "one" and "plurality" mentioned in the present invention are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise clearly indicated in the context, it should be understood as "one or more".

[0033] The names of the messages or information exchanged between multiple devices of the present invention are only for illustrative purposes, and are not used to limit the scope of these messages or information.

[0034] The present invention will be described in detail below with reference to the accompanying drawings and in conjunction with embodiments.

[0035] like Figure 1 FIG. 1 is a flow chart of a method for testing RTC clock offset under a Linux operating system according to the present invention, which specifically includes the following steps:

[0036] Step 101: determine whether the server to be tested is a local server.

[0037] In some embodiments, the executor of the RTC clock offset test method under a Linux operating system of the present invention can be a background server. The Linux operating system is a free and open source UNIX-like operating system. A UNIX-like operating system refers to a system that inherits the design concept and style of UNIX. The UNIX operating system is an operating system widely used in fields such as engineering applications and scientific computing. A local server generally refers to a server located in a local network or directly connected to a user terminal, which is responsible for providing network services or resources. A server is a specific Internet technology device that provides computing power and runs software applications in a network environment, and usually has the ability to respond to service requests, provide services, and ensure services.

[0038] In some embodiments, the execution subject establishes a communication connection with the server to be tested through various communication methods, and obtains its network information, including IP (Internet Protocol Address) address and subnet mask, and then determines whether the IP address of the server to be tested is within the known local network range. If the IP address is not within the local range, it further checks whether it is a public IP address. At the same time, the network delay is measured by the Ping (Packet Internet Groper) command. If the delay is within a reasonable range, for example, less than a specific number of milliseconds, it is confirmed that the server is a local server. In addition, the execution subject can obtain the device information of the server to be tested to verify the server characteristics, and combine the above information to make a final judgment: if the conditions of the local server are met, it is determined to be a local server, otherwise it is determined to be a remote server. Among them, the IP address is a unified address format provided by the IP protocol. It assigns a logical address to each network and each host on the Internet to shield the difference in physical addresses. The IP protocol is the network layer protocol in the TCP / IP (Transmission Control Protocol / Internet Protocol) system. The network layer protocol is the third layer of the OSI (Open System Interconnect) reference model. It controls the communication subnet to work, provides means to establish, maintain and release connections, and ensures transparent data transmission between transport layer entities. The logical address here is assigned by the IP protocol and is used to uniquely identify each network and host on the Internet. By using the logical address, the network layer can achieve unified management and addressing of different networks and hosts without knowing the specific physical address of the underlying hardware. The physical address usually refers to the MAC (Media Access Control Address) address or the specific address of other network hardware. It is the real address required for network devices to communicate in a local area network. The physical address directly corresponds to the hardware of the device without involving the logical management of the network layer.

[0039] Step 102, if the server to be tested is a local server, then perform the RTC clock offset test step: obtain the local time of the server to be tested at the first time point, determine the local time at the first time point as the first local time, synchronize the first local time with the Beijing time at the first time point through a pre-configured first script to obtain the synchronized first local time; obtain the RTC time of the local server at the first time point, and determine the RTC time at the first time point as the first RTC time; synchronize the first RTC time with the synchronized first local time through the RTC time synchronization instruction provided by the Linux operating system and the pre-configured first script to obtain the synchronized first local time. first RTC time; after the target time has passed, the RTC time of the local server at the second time point is determined as the second RTC time, and the local time of the local server at the second time point is determined as the second local time; through the local time synchronization instruction provided by the Linux operating system and the pre-configured first script, the second RTC time is synchronized to the second local time to obtain the synchronized second local time; through the pre-configured first script, a difference operation is performed on the synchronized second local time and the Beijing time at the second time point to obtain the calculation result of the difference operation, the calculation result is formed into a standard file, and the standard file is printed to the screen, and the calculation result is the RTC time offset value.

[0040] In some embodiments, first, the local time of the server to be tested at the first time point is obtained, and it is determined as the first local time. Then, the first local time is synchronized with the Beijing time at the first time point through the pre-configured first script to obtain the synchronized first local time. Next, the RTC time of the local server at the first time point is obtained, and it is determined as the first RTC time. The first RTC time is synchronized with the synchronized first local time using the RTC time synchronization instruction provided by the Linux operating system and the pre-configured first script to obtain the synchronized first RTC time. After the set target time, the RTC time of the local server at the second time point is obtained, and it is determined as the second RTC time, and the local time at the second time point is obtained, and it is determined as the second local time. Subsequently, the local time synchronization instruction provided by the Linux operating system and the pre-configured first script are used to synchronize the second RTC time to the second local time, and the synchronized second local time is obtained. Finally, the difference operation is performed on the synchronized second local time and the Beijing time at the second time point through the pre-configured first script to obtain the calculation result, the result is formed into a standard file, and printed to the screen, and this calculation result is the RTC time offset value.

[0041] In some embodiments, the execution subject has stored the pre-configured first script and the second script locally. If the server to be tested is a local server, the execution subject runs the pre-configured first script to perform the RTC clock offset test step: first, obtain the local time of the server to be tested at the first time point, and synchronize the time with Beijing time to obtain the first synchronized local time. Next, obtain the RTC time of the local server at the first time point, and synchronize it to the first local time to obtain the first synchronized RTC time. Subsequently, after the set target duration, obtain the RTC time and local time of the local server at the second time point, and synchronize the second RTC time to the second local time to obtain the synchronized second local time. Finally, through the pre-configured first script, calculate the difference between the synchronized second local time and the Beijing time at the second time point, obtain the RTC time offset value, and print it to the screen in the form of a standard file. Among them, the first time point is the test start time, and the second time point is the test end time. The target duration is the time difference between the start and end of the test. The synchronized time refers to the local time and RTC time synchronized with Beijing time. The local time is the current time of the time zone set by the server system to be tested. Beijing time is the national standard time adopted throughout China and is the zone time of the international time zone East 8. Synchronizing the first local time is the time when the first local time is synchronized with Beijing time at the beginning of the test. Script is an extension of batch files, a program saved in plain text, which can usually be temporarily called and executed by applications. The RTC time synchronization instruction is to synchronize the local time with the RTC time. Synchronizing the first RTC time is the time when the first RTC time is synchronized with the Beijing time at the first time point at the beginning of the test. At the beginning of the test, the synchronization of the first local time, the synchronization of the first RTC time and the Beijing time at the first time point are consistent. The target duration is the difference between the test start time and the test end time set according to the test requirements. The second time point is the time when the test ends. The local time synchronization instruction is to synchronize the RTC time with the local time. Synchronizing the second local time is the time when the second RTC time is synchronized with the second local time at the end of the test. The RTC time offset value is the test result obtained at the end of the RTC clock offset test.

[0042] In practice, as an example, the target duration of the RTC clock offset test is set to one hour, and the time formats used in this example are all in the millisecond time standard format. The local time of the local server at the first time point is 2024-10-1412:01:00.000, and the local time at the first time point is determined as the first local time, then the first local time is 2024-10-1412:01:00.000, and the Beijing time at the first time point is 2024-10-1412:00:00.000. The execution subject runs the pre-configured first script to synchronize the first local time with the Beijing time at the first time point, and obtains the synchronized first local time. At this time, the synchronized first local time is 2024-10-1412:00:00.000. The RTC time of the local server at the first time point is 2024-10-1412:02:00.000, and the RTC time at the first time point is determined as the first RTC time, that is, 2024-10-1412:02:00.000. The execution subject runs the RTC time synchronization instruction provided by the Linux operating system and the pre-configured first script, synchronizes the first RTC time with the synchronized first local time, and obtains the synchronized first RTC time. At this time, the synchronized first RTC time is 2024-10-1412:00:00.000. At this point, the value of the synchronized first local time and the value of the synchronized first RTC time are consistent with the Beijing time 2024-10-1412:00:00.000 at the first time point. After one hour, the Beijing time at the second time point is 2024-10-1413:00:00.000, and the RTC time of the local server at the second time point is determined as the second RTC time, and the second RTC time is 2024-10-1413:00:01.000, and the local time of the local server at the second time point is determined as the second local time; the execution subject runs the local time synchronization instruction provided by the Linux operating system and the pre-configured first script, synchronizes the second RTC time to the second local time, and obtains the synchronized second local time. At this time, the synchronized second local time is 2024-10-1413:00:01.000. The execution subject runs the pre-configured first script, performs a difference operation on the synchronized second local time and the Beijing time at the second time point, and obtains a calculation result of 1 second. This calculation result is the RTC time offset value, and the above calculation result is saved as a standard file and printed to the screen. A standard file format for printing to the screen in this example might be "The calculated RTC clock offset value is: ['+0.100000', 'sec']".

[0043] Step 103, if the server to be tested is a remote server, run the pre-configured second script, pop up a remote login information input window to receive the remote login information input by the user, establish a secure shell protocol ssh connection with the remote server according to the remote login information corresponding to the remote server, and execute the RTC clock offset test step to obtain the RTC time offset value of the remote server, form the RTC time offset value into a standard file, and print the standard file to the screen.

[0044] In some embodiments, if the server to be tested is a remote server, the execution subject establishes an ssh connection with the remote server, and executes the RTC clock offset test step to obtain the RTC time offset value of the remote server, the RTC time offset value is formed into a standard file, and the standard file is printed to the screen. The client runs the pre-configured second script, pops up a remote login information input window, prompts the user to enter the remote login information, and the user enters the corresponding remote login information through the remote login information input window. If the remote login information entered by the user is correct, the client will establish an ssh connection with the remote server. As an example, the remote login information includes the OS IP address, OS user name, and OS user password. After the connection is established, the client executes the RTC clock offset test step, saves the obtained RTC time offset value of the remote server as a standard file, and prints the standard file to the client's screen. The standard file format in this example can be "the RTC clock offset value is calculated as: ['+0.100000', 'sec']". Among them, the remote server refers to a computer server that is remotely accessed and managed through the Internet or other networks, which can be run in a remote location, and the user can use a terminal device to connect and access the server's resources and services anywhere. SSH is a relatively reliable protocol designed to provide security for remote login sessions and other network services.

[0045] In these embodiments, the accuracy of the test results is improved by improving the RTC clock offset test method. Specifically, all times are synchronized at the beginning of the test, and any time synchronization operation is avoided during the test. At the end of the test, Beijing time is automatically obtained, and the obtained RTC time is synchronized to the local time of the server to calculate the difference between the two, thereby obtaining the RTC time offset value. The traditional method of directly calculating the difference between the RTC time and the Beijing time may produce a large error, but by calculating the difference between the synchronized local time and the Beijing time, the error can be significantly reduced. In addition, automatic acquisition of test time data is more efficient and accurate than manual acquisition, thereby improving the efficiency and accuracy of test data acquisition, avoiding error fluctuations caused by manual operations, and making the test results more reliable.

[0046] In some embodiments, in order to further solve the second technical problem described in the background technology section, that is, "in the prior art, a unified calibration interval is usually adopted for different servers, such as 24 hours. This fixed solution cannot meet the personalized needs of different types of servers; in addition, the prior art lacks an effective RTC module failure analysis method, resulting in the inability to identify and solve potential problems in a timely manner", in some embodiments of the present invention, a RTC clock offset test method under a Linux operating system also includes:

[0047] Step 1: determine the offset level of the server to be tested according to the RTC time offset value; and query the standard calibration interval duration corresponding to the offset level in a pre-configured calibration interval duration table according to the offset level.

[0048] In some embodiments, first, the current RTC time offset value is obtained from the server to be tested, and the obtained RTC time offset value is compared with the preset offset standard to be classified into different offset levels. The offset standard refers to the preset acceptance range of the RTC time offset, which is used to evaluate the time offset of the server to be tested; the offset refers to the current RTC time offset value obtained from the server to be tested, which indicates the actual degree of time offset; the offset level can be divided into multiple levels according to the size of the offset, such as "slight offset", "medium offset" and "severe offset". Then, in the pre-configured calibration interval duration table, the corresponding standard calibration interval duration is queried according to the determined offset level. For example, a slight offset may correspond to calibration every 48 hours, a medium offset corresponds to calibration every 24 hours, and a severe offset may require calibration every 12 hours.

[0049] Step two, obtain the time accuracy requirement level of the server to be tested, determine the adjustment coefficient corresponding to the time accuracy requirement level, generate the target calibration interval duration according to the standard calibration interval duration and the adjustment coefficient, send the target calibration interval duration to the server to be tested, so that the server to be tested performs time calibration according to the target calibration interval duration, generate a calibration record and store the calibration record in the database, the calibration record includes the calibration time point and the calibration time difference.

[0050] In some embodiments, first, the time accuracy requirement level is determined according to the application program run by the server to be tested and its specific requirements for time accuracy. Then, a mapping relationship is defined to associate different time accuracy requirement levels (e.g., high, medium, and low) with corresponding adjustment coefficients. This mapping relationship can be stored in a configuration table or dictionary so that the system can quickly find it during operation. For example, the adjustment coefficient for high accuracy requirements (e.g., microsecond level) is 0.5, the adjustment coefficient for medium accuracy requirements (e.g., millisecond level) is 1.0, and the adjustment coefficient for low accuracy requirements (e.g., second level) is 2.0. Based on the standard calibration interval duration and adjustment coefficient queried in the above step 1, the target calibration interval duration is generated. The specific calculation method can be the multiplication of the standard calibration interval duration and the adjustment coefficient. For example, if the standard calibration interval duration is 24 hours and the adjustment coefficient is 1.5, the target calibration interval duration is 24 hours multiplied by 1.5, i.e., 36 hours. Then, the target calibration interval is sent to the server to be tested, so that it can perform time calibration according to the target calibration interval. After each time calibration, the server generates a calibration record, which includes the calibration time point and the calibration time difference. Among them, the calibration time point is the specific timestamp when the time calibration operation is performed. It records the time when the calibration operation starts or ends, usually expressed in the format of date and time. For example, if the calibration operation is performed at 10 am on November 5, 2024, the calibration time point will be recorded as "2024-11-0510:00:00"; the calibration time difference refers to the difference between the RTC time of the server to be tested and the standard time during the calibration process. This difference can be positive or negative. If it is a positive value, it means that the RTC time of the server to be tested is faster than the standard time, that is, the current RTC time exceeds the standard time. If it is a negative value, it means that the RTC time of the server to be tested is slower than the standard time, that is, the current RTC time is lower than the standard time. Finally, these calibration records are stored in a database. A database refers to a data system used to store, manage and retrieve calibration records.

[0051] Step three, obtain the calibration record set within the target historical time period from the database, calculate the calibration time difference change trend corresponding to the target historical time period based on the calibration record set, and the calibration time difference change trend is stable or increasing; if the calibration time difference change trend is stable, generate first state information representing that the offset of the server to be tested is in a stable state; if the calibration time difference change trend is increasing, generate second state information representing that the offset of the server to be tested is in an unstable state, and based on the second state information, generate adjustment information for the target calibration interval duration or RTC module repair prompt information for the server to be tested.

[0052] In some embodiments, first, a calibration record set within a target historical time period is obtained from a database, and a calibration time difference change trend within the target historical time period is calculated based on each calibration record in the calibration record set, and the calibration time difference change trend can be stable or increasing. If the calibration time difference change trend is stable, a first state information is generated to characterize that the offset of the server to be tested is in a stable state. If the calibration time difference change trend is increasing, a second state information is generated to characterize that the offset of the server to be tested is in an unstable state, and based on the second state information, adjustment information for the target calibration interval duration or RTC module repair prompt information for the server to be tested is generated. Among them, the calibration record set refers to a collection of multiple calibration records obtained from the database within a specific time period, which contains detailed information of each calibration operation, such as the calibration time point and the calibration time difference. By analyzing these records, the changing trend of the time offset can be understood; the changing trend of the calibration time difference is obtained by extracting the calibration records from the database, arranging them in chronological order, calculating the change of each calibration time difference, and then calculating the average of these changes to determine whether the calibration time difference tends to be stable or increases; the adjustment information can be a modification suggestion for the target calibration interval duration generated based on the changing trend of the calibration time difference, for example, if the changing trend of the calibration time difference increases, the system may suggest shortening the calibration interval duration to calibrate the time more frequently, thereby reducing the offset; the RTC module repair prompt information for the server to be tested refers to the prompt information generated by the system when it is detected that the changing trend of the calibration time difference increases and adjusting the calibration interval duration cannot solve the problem, for example, it is suggested to check or repair the RTC module.

[0053] In these embodiments, the calibration accuracy of the RTC clock and the health management capability of the module are significantly improved by setting personalized calibration interval durations for different servers and an effective RTC module fault analysis method. The calibration interval duration is dynamically adjusted according to the actual offset level and time accuracy requirements of the server to ensure that each server can maintain the best time accuracy in its specific environment. At the same time, combined with the trend analysis of the calibration records, potential failures of the RTC module can be identified in a timely manner to ensure stable operation of the system. By collecting and analyzing the calibration records, the system can generate information characterizing the status of the server and make adjustments or repairs when necessary, thereby reducing the risk of data errors and information loss caused by time deviations and improving overall production efficiency and system reliability.

[0054] In some embodiments, in order to further solve the technical problem 3 described in the background technology section, that is, "the application installation method in the prior art directly installs the program without first determining the time accuracy requirement of the program, ignoring the differences in the application's time accuracy requirements, which may cause the time error in operation to affect the application performance and data accuracy", in some embodiments of the present invention, a RTC clock offset test method under the Linux operating system also includes:

[0055] Step 1: Obtain a pre-configured time accuracy query table, where the time accuracy query table includes multiple application categories and a time accuracy requirement sub-level corresponding to each application category.

[0056] In some embodiments, the execution subject queries a locally stored time accuracy query table, which contains multiple application categories, each of which corresponds to one or more time accuracy requirement sub-levels. Application categories refer to the classification of different application programs into several categories based on their functions and characteristics. For example, application categories may include financial applications, game applications, real-time communication applications, etc. Different application categories may have different requirements for time accuracy; the time accuracy query table is a pre-configured data structure for storing different application categories and their corresponding time accuracy requirement sub-levels;

[0057] Step two, determine the time accuracy requirement level of the server to be tested as the benchmark time accuracy requirement level, determine the application list of the server to be tested, the application list includes the application name and the application category corresponding to the application name; query the actual time accuracy requirement sub-level corresponding to each application name from the time accuracy query table, and update the actual time accuracy requirement sub-level to the application list to obtain an updated application list; send the updated application list, time accuracy query table and benchmark time accuracy requirement level to the server to be tested to perform subsequent operations.

[0058] In some embodiments, first, the time accuracy requirement level of the server to be tested is determined as the reference time accuracy requirement level, and a list of currently installed applications is obtained from the server to be tested, the list including the name of each application and its corresponding application category. Subsequently, the actual time accuracy requirement sub-level corresponding to each application name is queried from the time accuracy query table, and these actual time accuracy requirement sub-levels are updated to the application list to form an updated application list. Finally, the updated application list, the time accuracy query table and the reference time accuracy requirement level are sent to the server to be tested so that it can perform subsequent operations based on these information when installing the application. Among them, the reference time accuracy requirement level refers to the minimum time accuracy standard required by the server to be tested under a specific environment. It is usually a reference value set according to the actual application requirements and system performance requirements of the server. The determination of this level helps to ensure that the server can meet the time accuracy requirements of all installed applications during operation, avoiding performance degradation or data errors caused by insufficient time accuracy.

[0059] Step three, when a new application installation request is detected, determine the application category of the new application, and query the time accuracy query table based on the application category of the new application to obtain the actual time accuracy requirement sub-level corresponding to the new application. If the actual time accuracy requirement sub-level is lower than the benchmark time accuracy requirement level, the new application is allowed to be installed.

[0060] In some embodiments, when the system of the server to be tested detects an installation request for a new application, it identifies the application category of the new application involved in the request, and queries the time accuracy query table based on the application category of the new application to obtain the actual time accuracy requirement sub-level corresponding to the new application, and compares the actual time accuracy requirement sub-level with a pre-set benchmark time accuracy requirement level. If it is found that the actual requirement is lower than the benchmark level, the application is allowed to be installed.

[0061] Step 4: If the actual time accuracy requirement sub-level is higher than the benchmark time accuracy requirement level, a time error risk warning message and a user command input control are displayed in a pop-up window. The time error risk warning message is used to prompt that there is a time error risk during the operation of the new application. The user command input control is used to receive user commands entered by the user in response to the time error risk warning message. User commands indicate ignoring the risk or stopping the installation.

[0062] In some embodiments, when the system of the server to be tested detects that the actual time accuracy requirement sub-level of the new application is higher than the benchmark time accuracy requirement level, it indicates that the application may face a greater risk of time error during operation. At this time, the execution entity will display the time error risk prompt information to the user in the form of a pop-up window, informing the user that the application may not be able to run normally in the current time accuracy environment, and the current time accuracy will affect its performance and data accuracy. At the same time, a control for receiving user command input will be provided in the pop-up window so that the user can respond to the risk prompt. The control commands include ignoring risks and stopping installation. If the received instruction is to ignore the risk, continue to install the application; if the received instruction is to stop installation, terminate the installation of the program.

[0063] Step five, if the user instruction indicates that the risk is ignored, the application name with the highest time accuracy requirement sub-level in the update application list is determined as the baseline application name, and the actual time accuracy requirement sub-level is compared with the time accuracy requirement sub-level corresponding to the baseline application name. If the actual time accuracy requirement sub-level is less than or equal to the time accuracy requirement sub-level corresponding to the baseline application name, the new application is allowed to be installed.

[0064] In some embodiments, if the control receiving the user instruction input receives the command to ignore the risk, the new application will continue to be installed, and the system will identify the application with the highest time accuracy requirement sub-level from the updated application list and determine its name as the benchmark application name. The selection of this benchmark application name is based on its highest requirement for time accuracy, and is intended to provide a reliable reference standard for the installation of new applications. Subsequently, the execution entity will compare the actual time accuracy requirement sub-level of the new application with the time accuracy requirement sub-level corresponding to the benchmark application name. If it is found that the actual time accuracy requirement sub-level of the new application is less than or equal to the time accuracy requirement sub-level of the benchmark application, the installation of the new application is allowed.

[0065] In these embodiments, by determining the time accuracy requirements of the program before installing the application, it is ensured that only applications that meet the preset time accuracy requirements can be installed, thereby effectively reducing the impact of time errors on application performance and data accuracy. This method not only improves the overall time management capabilities of the system, but also enhances the compatibility between different applications, allowing the system to dynamically adjust the time accuracy standard according to actual needs, ensuring that various applications can stably and accurately calculate time during operation, thereby improving system efficiency.

[0066] In some embodiments, in order to further solve the technical problem 4 described in the background technology section, that is, "in the prior art, before running the script on the server to be tested to perform the RTC clock offset test, the command differences between different Linux system distributions are not taken into account. Such differences may cause the script to fail to execute successfully in some distribution systems, thereby causing the test to fail." In some embodiments of the present invention, a method for testing RTC clock offset under a Linux operating system also includes:

[0067] Step 1: Collect the command differences between common Linux system distributions, organize them and save them locally to form files.

[0068] In some embodiments, the execution subject collects and organizes the command differences between common Linux distributions (such as Ubuntu, Fedora, Debian, CentOS, Arch Linux, etc.) to form a system command difference information table. The table should contain the correspondence between different commands with the same function under different Linux distributions. Among them, the Linux system distribution refers to the operating system version based on the Linux kernel. Different development teams and organizations can modify and customize it according to specific needs and goals. Common Linux distributions include Ubuntu, Fedora, Debian, CentOS, Arch Linux, etc.

[0069] Step 2: Determine whether the server to be tested is a remote server or a local server.

[0070] In some embodiments, the execution entity completes the server type judgment through the aforementioned step 101. If the server to be tested is a remote server, the required remote login information is first obtained, such as the IP address, login username and password, and then ssh is used to connect to the remote server. After the login is successful, subsequent operations are performed, otherwise the operation is terminated and an error message is returned; if the server to be tested is a local server, the subsequent steps are performed directly.

[0071] Step 3: Use the server command to obtain server information and generate a system information file and save it locally.

[0072] In some embodiments, after the execution subject successfully logs in to the server, it uses a command to obtain the server information, including the host name, operating system version, kernel version and hardware architecture of the current system, and saves it as a system information table in the directory where the script for performing the RTC clock offset test is located, waiting for matching with the system command difference information table. Among them, the server command can be hostnamectl, which is a command line tool for querying and setting the system host name and related network configurations, and it is part of the system and service manager. Through hostnamectl, users can view and modify information such as the system's host name, operating system version, kernel version and hardware architecture. This command usually exists in different Linux distributions and is relatively consistent in usage, so it is very convenient and commonly used in system information acquisition and management. Among them, the kernel version refers to the specific version number of the operating system kernel. The kernel is the core part of the operating system, responsible for managing the interaction between system resources, hardware devices and software processes. Different kernel versions may contain different functional improvements, security fixes, performance optimizations and hardware support; hardware architecture refers to the organization and structure of various hardware components in a computer system, including their mutual connection methods and working mechanisms, such as central processing units (CPUs), memory (RAMs), etc.

[0073] Step 4: Check the system command difference information table, compare the system information table, match the system version of the server to be tested, and determine whether there is a command difference.

[0074] In some embodiments, the execution subject extracts the specific Linux system release version information of the current server to be tested from the system information table, matches the version name with the previously collected system command difference information table, and checks whether there are difference commands in the current system version.

[0075] Step 5: After completing the matching between the system information table of the server to be tested and the system command difference information table, incompatible commands in the script used for the RTC clock offset test are identified and replaced.

[0076] In some embodiments, after the execution entity completes the matching of the system information table of the server to be tested with the system command difference information table, if any difference commands are found, the incompatible parts of the script used for the RTC clock offset test are replaced with commands suitable for the current distribution version to ensure that it can be executed normally on the current Linux system distribution version.

[0077] Step 6: After completing the replacement of incompatible commands in the script used for the RTC clock offset test, confirm that the script has been adapted to the current Linux distribution, and then continue to run the script to perform the aforementioned RTC clock offset test.

[0078] In some embodiments, by executing the above steps, the difference command replacement of different systems in the script has been completed, and the above step 102 or 103 can be performed to complete the RTC clock offset test.

[0079] In these embodiments, by identifying the command differences between different Linux distributions, the accuracy and reliability of the RTC clock offset test can be significantly improved, and the risk of test failure caused by command incompatibility can be reduced, thereby ensuring the validity and consistency of the test results. This method improves the stability of the RTC clock offset test script on different Linux system distributions and provides strong support for the precise management of system time.

[0080] The above descriptions are only some preferred embodiments of the present invention and the explanation of the technical principles used. Those skilled in the art should understand that the scope of the invention involved in the present invention is not limited to the technical solutions formed by the specific combination of the above technical features, but also should cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above inventive concept. For example, the above features are replaced with the technical features with similar functions disclosed in the present invention (but not limited to) to form a technical solution.

Claims

1. A method for testing RTC clock offset under Linux operating system, characterized in that: include: Determine whether the server to be tested is a local server; If the server to be tested is a local server, the RTC clock offset test step is performed: the local time of the server to be tested at the first time point is obtained, the local time at the first time point is determined as the first local time, and the first local time is synchronized with the Beijing time at the first time point through a pre-configured first script to obtain a synchronized first local time; the RTC time of the local server at the first time point is obtained, and the RTC time at the first time point is determined as the first RTC time; the first RTC time is synchronized with the synchronized first local time through the RTC time synchronization instruction provided by the Linux operating system and the pre-configured first script to obtain a synchronized first RTC time; After the target duration has passed, the RTC time of the local server at the second time point is determined as the second RTC time, and the local time of the local server at the second time point is determined as the second local time; the second RTC time is synchronized to the second local time through the local time synchronization instruction provided by the Linux operating system and the pre-configured first script to obtain the synchronized second local time; through the pre-configured first script, a difference operation is performed on the synchronized second local time and the Beijing time at the second time point to obtain a calculation result of the difference operation, the calculation result is formed into a standard file, and the standard file is printed to the screen, and the calculation result is an RTC time offset value; If the server to be tested is a remote server, a pre-configured second script is run, a remote login information input window pops up to receive the remote login information input by the user, a secure shell protocol ssh connection is established with the remote server according to the remote login information corresponding to the remote server, and the RTC clock offset test step is executed to obtain the RTC time offset value of the remote server, the RTC time offset value is formed into a standard file, and the standard file is printed to the screen.

2. The RTC clock offset test method under the Linux operating system according to claim 1, characterized in that: Also includes: Determine the offset level of the server to be tested according to the RTC time offset value; According to the offset level, querying a pre-configured calibration interval duration table for a standard calibration interval duration corresponding to the offset level; Obtaining the time accuracy requirement level of the server to be tested, determining the adjustment coefficient corresponding to the time accuracy requirement level, generating a target calibration interval duration according to the standard calibration interval duration and the adjustment coefficient, sending the target calibration interval duration to the server to be tested so that the server to be tested performs time calibration according to the target calibration interval duration, generating a calibration record and storing the calibration record in a database, wherein the calibration record includes a calibration time point and a calibration time difference; Acquire a calibration record set within a target historical time period from the database, and calculate a calibration time difference change trend corresponding to the target historical time period according to the calibration record set, wherein the calibration time difference change trend is stable or increasing; If the change trend of the calibration time difference is stable, generating first state information indicating that the offset of the server to be tested is in a stable state; If the calibration time difference changes in a larger trend, second status information is generated to indicate that the offset of the server to be tested is in an unstable state, and based on the second status information, adjustment information for the target calibration interval duration or RTC module repair prompt information for the server to be tested is generated.

3. The RTC clock offset test method under the Linux operating system according to claim 2, characterized in that: Also includes: Obtaining a preconfigured time accuracy query table, wherein the time accuracy query table includes multiple application categories and a time accuracy requirement sub-level corresponding to each application category; The time accuracy requirement level of the server to be tested is determined as the benchmark time accuracy requirement level, and an application list of the server to be tested is determined, wherein the application list includes application names and application categories corresponding to the application names; the actual time accuracy requirement sub-level corresponding to each application name is queried from the time accuracy query table, and the actual time accuracy requirement sub-level is updated to the application list to obtain an updated application list; the updated application list, the time accuracy query table, and the benchmark time accuracy requirement level are all sent to the server to be tested, so that the server to be tested performs the following operations: When a request to install a new application is detected, the application category of the new application is determined, and the time accuracy query table is queried based on the application category of the new application to obtain the actual time accuracy requirement sub-level corresponding to the new application. If the actual time accuracy requirement sub-level is lower than the benchmark time accuracy requirement level, the new application is allowed to be installed.

4. The RTC clock offset test method under the Linux operating system according to claim 3, characterized in that: Also includes: If the actual time accuracy requirement sub-level is higher than the benchmark time accuracy requirement level, time error risk warning information and a user command input control are displayed via a pop-up window. The time error risk warning information is used to prompt that there is a time error risk during the operation of the new application. The user command input control is used to receive user commands entered by the user in response to the time error risk warning information. The user command indicates ignoring the risk or stopping the installation.

5. The RTC clock offset test method under the Linux operating system according to claim 4, characterized in that: Also includes: If the user instruction represents ignoring risk, the application name with the highest time accuracy requirement sub-level in the updated application list is determined as the benchmark application name, and the actual time accuracy requirement sub-level is compared with the time accuracy requirement sub-level corresponding to the benchmark application name; if the actual time accuracy requirement sub-level is less than or equal to the time accuracy requirement sub-level corresponding to the benchmark application name, the new application is allowed to be installed.

Images