CN119512316A - A method for testing RTC clock offset under Linux operating system - Google Patents
A method for testing RTC clock offset under Linux operating system Download PDFInfo
- Publication number
- CN119512316A CN119512316A CN202411566438.6A CN202411566438A CN119512316A CN 119512316 A CN119512316 A CN 119512316A CN 202411566438 A CN202411566438 A CN 202411566438A CN 119512316 A CN119512316 A CN 119512316A
- Authority
- CN
- China
- Prior art keywords
- time
- server
- rtc
- local
- calibration
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
- G06F1/04—Generating or distributing clock signals or signals derived directly therefrom
- G06F1/10—Distribution of clock signals, e.g. skew
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
本发明涉及计算机应用技术领域，公开了一种Linux操作系统下RTC时钟偏移测试方法，包括，RTC时钟偏移测试步骤：首先通过判断待测试服务器是否为本地服务器来确定测试类型。若为本地服务器，则获取第一时间点的本地时间和RTC时间，通过预配置的脚本进行时间同步，随后获取第二时间点的RTC时间和本地时间，计算偏移值并生成标准文件展示结果。若为远程服务器，则弹出远程登录信息输入窗口，用户输入后建立SSH连接并执行相同测试，获取RTC时间偏移值并生成标准文件。由此，实现了Linux操作系统下的RTC时钟偏移测试。
The present invention relates to the field of computer application technology, and discloses an RTC clock offset test method under a Linux operating system, including an RTC clock offset test step: first, determine the test type by judging whether the server to be tested is a local server. If it is a local server, obtain the local time and RTC time at a first time point, perform time synchronization through a preconfigured script, then obtain the RTC time and local time at a second time point, calculate the offset value, and generate a standard file to display the result. If it is a remote server, a remote login information input window pops up, and after the user inputs, an SSH connection is established and the same test is performed to obtain the RTC time offset value and generate a standard file. Thus, the RTC clock offset test under the Linux operating system is realized.
Description
Technical Field
The invention relates to the technical field of computer application, in particular to a RTC clock offset test method under a Linux operating system.
Background
The RTC (Real-Time Clock) is a device that is independent from the system timer and is used to set the system Clock, provide an alarm or a periodic timer. The RTC can accurately track time, is not affected by device power outages, and is therefore an important component of many devices. For electronic products used in daily life, such as GPS in mobile phones, computers, watches, and automobiles, RTC plays a key role. Measuring the RTC refers to testing and adjusting the real-time clock of the device, ensuring that the device can accurately record time. In order to ensure proper operation of the system and equipment, the accuracy of the RTC is of paramount importance to be measured regularly. The accuracy of the RTC is measured and adjusted, normal operation of equipment and a system can be ensured, data errors and information loss are prevented, and therefore production efficiency and system stability are improved. At present, RTC clock offset test is mainly performed by checking RTC time at BIOS (Basic Input Output System ) interface, comparing with Beijing time, and after a period of time, comparing with Beijing time again under the condition of not performing RTC time synchronization operation to measure RTC clock offset value, requiring RTC clock offset of not more than + -1.8 seconds every day (24 hours), or under OS (Operating System), acquiring RTC time by instruction, comparing with Beijing time, and after a period of time comparing with Beijing time again to see whether RTC time offset value meets the requirement of not more than + -1.8 seconds every day (24 hours).
The existing RTC clock offset test method often has the following technical problems:
Firstly, in the current RTC clock offset test, RTC time is checked at a BIOS interface and compared with Beijing time, offset is judged by naked eye observation, and comparison is performed by the same method under an OS, and the method has larger test data error due to the fact that the naked eye observation is relied on, so that the accuracy of a test result is affected;
secondly, in the prior art, uniform calibration interval time length is usually adopted for different servers, such as 24 hours, and the fixing scheme cannot meet the personalized requirements of different types of servers;
Thirdly, the application installation mode in the prior art does not judge the requirement of the program on the time precision first to be directly installed, so that the difference of the application on the time precision requirement is ignored, and the time error in the operation possibly affects the application performance and the data accuracy;
Fourth, in the prior art, before the script is run on the server to be tested to perform RTC clock offset test, command differences existing between different Linux system release boards are not considered, and the differences may cause that in some release board systems, the script cannot be successfully executed, so that the test fails.
Disclosure of Invention
This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
The invention provides a method for testing RTC clock offset under a Linux operating system, which aims to solve one or more of the technical problems mentioned in the background section.
The invention provides a RTC clock offset test method under a Linux operating system, which comprises the following steps:
judging whether the server to be tested is a local server or not;
If the server to be tested is a local server, executing an RTC clock offset test step, namely acquiring the local time of the server to be tested at a first time point, determining the local time of the first time point as a first local time, synchronizing the first local time with the Beijing time of the first time point through a preconfigured first script to obtain a synchronous first local time, acquiring the RTC time of the local server at the first time point, determining the RTC time of the first time point as a first RTC time, synchronizing the first RTC time with the synchronous first local time through an RTC time synchronizing instruction provided by a Linux operating system and a preconfigured first script to obtain a synchronous first RTC time, determining the RTC time of the local server at a second time point as a second RTC time after the target time is passed, synchronizing the second time to the second local time through a local time synchronizing instruction provided by a Linux operating system and the preconfigured first script, forming a result of a digital value with a first RTC, and calculating a result of a digital value, and calculating the value of the difference between the first RTC time and the first local time to obtain a result of the synchronization;
If the server to be tested is a remote server, a second script which is configured in advance is operated, a remote login information input window is popped up to receive remote login information input by a user, a secure shell protocol ssh connection is established with the remote server according to the remote login information corresponding to the remote server, an RTC clock offset testing step is executed to obtain an 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 on a screen.
Optionally, the RTC clock offset test method under the Linux operating system further comprises the steps of determining an offset level of a server to be tested according to the RTC time offset value;
Obtaining a time precision requirement level of a server to be tested, determining an adjustment coefficient corresponding to the time precision requirement level, generating a target calibration interval duration according to a standard calibration interval duration and the adjustment coefficient, and 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 comprises a calibration time point and a calibration time difference;
The method comprises the steps of obtaining a calibration record set in a target historical time period from a database, calculating a calibration time difference change trend corresponding to the target historical time period according to the calibration record set, generating first state information representing that the offset of a server to be tested is in a stable state if the calibration time difference change trend is stable, generating second state information representing that the offset of the server to be tested is in an unstable state if the calibration time difference change trend is large, and generating adjustment information aiming at the target calibration interval duration or RTC module repair prompt information aiming at the server to be tested according to the second state information.
Optionally, the RTC clock offset test method under the Linux operating system further comprises the steps of obtaining a pre-configured time precision lookup table, wherein the time precision lookup table comprises a plurality of application categories and time precision requirement sub-levels corresponding to each application category;
Determining a time precision requirement level of a server to be tested as a reference time precision requirement level, determining an application program list of the server to be tested, wherein the application program list comprises application program names and application categories corresponding to the application program names, inquiring actual time precision requirement sub-levels corresponding to each application program name from a time precision inquiry table, updating the actual time precision requirement sub-levels into the application program list to obtain an updated application program list, and transmitting the updated application program list, the time precision inquiry table and the reference time precision requirement level to the server to be tested so as to enable the server to be tested to execute the following operations:
When a new application program installation request is detected, determining an application type of the new application program, inquiring in a time precision inquiry table according to the application type of the new application program to obtain an actual time precision requirement sub-level corresponding to the new application program, and allowing the new application program to be installed if the actual time precision requirement sub-level is lower than a reference time precision requirement level.
Optionally, the RTC clock offset testing method under the Linux operating system further comprises the steps of displaying time error risk prompt information and a user instruction input control through a popup window if the actual time precision requirement sub-level is higher than the reference time precision requirement level, wherein the time error risk prompt information is used for prompting that time error risks exist in the running process of a new application program, the user instruction input control is used for receiving a user instruction input by a user aiming at the time error risk prompt information, and the user instruction represents neglecting risks or stopping installation.
Optionally, the RTC clock offset testing method under the Linux operating system further comprises the steps of determining an application program name with the highest time precision requirement sub-level in the updated application program list as a reference application program name if the user instruction characterizes neglect risk, comparing the actual time precision requirement sub-level with the time precision requirement sub-level corresponding to the reference application program name, and allowing a new application program to be installed if the actual time precision requirement sub-level is smaller than or equal to the time precision requirement sub-level corresponding to the reference application program name.
The invention has the following beneficial effects:
1. By improving the RTC clock offset test method, the accuracy of the test result is improved. In particular, all times are synchronized at the beginning of the test and any time synchronization operations are avoided during the test. And after the test is finished, automatically acquiring Beijing time, and synchronizing the acquired RTC time to the local time of the server to calculate the difference between the Beijing time and the local time, so as to obtain the RTC time offset value. The conventional method may generate a larger error when directly calculating the difference between the RTC time and the beijing time, and the error can be significantly reduced by calculating the difference between the synchronized local time and the beijing time. In addition, the automatic acquisition of the test time data is more efficient and accurate compared with the manual acquisition, so that the acquisition efficiency and accuracy of the test data are improved, error fluctuation caused by manual operation is avoided, and the test result is more reliable;
2. by setting the personalized calibration interval time length for different servers and an effective RTC module fault analysis method, the calibration precision of an RTC clock and the health management capability of the module are obviously improved. According to the actual offset level and time precision requirement of the servers, the calibration interval duration is dynamically adjusted, so that each server can maintain optimal time precision in a specific environment. Meanwhile, by combining trend analysis of the calibration records, potential faults of the RTC module can be timely identified, and stable operation of the system is ensured, so that data errors and information loss risks caused by time deviation are reduced, and the overall production efficiency and the system reliability are improved;
3. By judging the time precision requirement of the program before application installation, only the application meeting the preset time precision requirement can be ensured to be installed, so that the influence of time errors on the application performance and the data accuracy is effectively reduced. The method not only improves the time management capability of the whole system, but also enhances the compatibility among different applications, so that the system can dynamically adjust the time precision standard according to actual demands, ensure that various applications can stably and accurately perform time calculation in the running process, and further improve the system efficiency;
4. By identifying command differences among different Linux release plates, accuracy and reliability of RTC clock offset test can be remarkably improved, and test failure risk caused by command incompatibility is reduced, so that validity and consistency of test results are ensured. The method improves the stability of RTC clock offset test scripts on different release boards of Linux systems, and provides powerful support for accurate management of system time.
Drawings
The above and other features, advantages and aspects of embodiments of the present invention will become more apparent by reference to the following detailed description when taken in conjunction with the accompanying drawings. The same or similar reference numbers will be used throughout the drawings to refer to the same or like elements. It should be understood that the figures are schematic and that elements and components are not necessarily drawn to scale.
FIG. 1 is a flow chart of a method for testing RTC clock offset in a Linux operating system.
Detailed Description
The invention will be described in more detail below with reference to the accompanying drawings. While certain embodiments of the invention have been illustrated in the accompanying drawings, it is to be understood that the invention may be embodied in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete. It should be understood that the drawings and embodiments of the invention are for illustration purposes only and are not intended to limit the scope of the present invention.
It should be noted that, for convenience of description, only the portions related to the present invention are shown in the drawings. Embodiments of the invention and features of the embodiments may be combined with each other without conflict.
It should be noted that the terms "first," "second," and the like herein are merely used for distinguishing between different devices, modules, or units and not for limiting the order or interdependence of the functions performed by such devices, modules, or units.
It should be noted that references to "one", "a plurality" and "a plurality" in this disclosure are intended to be illustrative rather than limiting, and those skilled in the art will appreciate that "one or more" is intended to be construed as "one or more" unless the context clearly indicates otherwise.
The names of messages or information interacted between the devices of the present invention are for illustrative purposes only and are not intended to limit the scope of such messages or information.
The invention will be described in detail below with reference to the drawings in connection with embodiments.
As shown in FIG. 1, the flow chart of the RTC clock offset test method under the Linux operating system specifically comprises the following steps:
Step 101, judging whether the server to be tested is a local server.
In some embodiments, an execution subject of the RTC clock offset test method under the Linux operating system of the present invention may be a background server. The Linux operating system is a free and open source UNIX-like operating system. The UNIX-like operating system refers to a system that inherits the UNIX design concepts and styles. The UNIX operating system is an operating system widely used in the fields of engineering application, scientific computing, and the like. A local server generally refers to a server located in a local network or directly connected to a user terminal, and is responsible for providing network services or resources. A server is a particular internet technology device that provides computing power and runs software applications in a network environment, and typically has the ability to afford to respond to requests for services, to afford to service, and to secure services.
In some embodiments, the executing entity establishes a communication connection with the server to be tested through various communication modes and acquires its network information including an IP (Internet Protocol Address, internet protocol) address and a subnet mask, then determines whether the IP address of the server to be tested is within a known local network range, further checks whether it is a public IP address if the IP address is not within the local range, and at the same time, instructs to measure network delay by Ping (PACKET INTERNET Groper, internet packet explorer) and confirms that the server is a local server if the delay is within a reasonable range, for example, less than a specific number of milliseconds. In addition, the executing body can acquire the equipment information of the server to be tested to verify the characteristics of the server, and the final judgment is obtained by integrating the above information, wherein if the condition of the local server is met, the local server is judged, and otherwise, the remote server is judged. The IP address is a unified address format provided by the IP protocol, which allocates a logic address to each network and each host on the Internet so as to shield the difference of physical addresses, the IP protocol is a network layer protocol in a TCP/IP (Transmission Control Protocol/Internet Protocol ) system, the network layer protocol is a third layer of an OSI (Open System Interconnect, open system interconnection) reference model, and the IP address control system controls the operation of a communication sub-network, provides means for establishing, maintaining and releasing connection, and ensures transparent data transmission between transmission layer entities. The logical addresses are assigned by the IP protocol for uniquely identifying each network and host in the internet, and by using the logical addresses, 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 generally refers to a MAC (MEDIA ACCESS Control Address) Address or a specific Address of other network hardware, which is a real Address required when the network device communicates in the lan, and corresponds directly to the hardware of the device, without involving the logical management of the network layer.
Step 102, if the server to be tested is a local server, executing an RTC clock offset test step, namely acquiring the local time of the server to be tested at a first time point, determining the local time of the first time point as a first local time, synchronizing the first local time with the Beijing time of the first time point through a preconfigured first script to obtain a synchronized first local time, acquiring the RTC time of the local server at the first time point, determining the RTC time of the first time point as a first RTC time, synchronizing the first RTC time with the synchronized first local time through an RTC time synchronization instruction provided by a Linux operating system and a preconfigured first script to obtain a synchronized first RTC time, determining the RTC time of the local server at a second time point as a second local time after a target time is passed, synchronizing the second time to the first RTC time through a local time synchronization instruction provided by a Linux operating system and the preconfigured first script, calculating a value of the difference between the second time and the first RTC time, and the first RTC time is a synchronization result, and a value is calculated, and a standard value is obtained by calculating the value of the difference between the first RTC and the first local time and the first script.
In some embodiments, the local time of the server under test at the first point in time is first obtained and determined as the first local time. And then, synchronizing the first local time with the Beijing time at the first time point through a pre-configured first script to obtain a synchronized first local time. Next, RTC time of the local server at the first point in time is obtained and determined as the first RTC time. And synchronizing the first RTC time with the synchronized first local time by using an RTC time synchronization instruction provided by the Linux operating system and a preconfigured first script to obtain the synchronized first RTC time. After the set target duration is elapsed, acquiring the RTC time of the local server at a second time point, determining the RTC time as the second RTC time, acquiring the local time of the second time point, and determining the local time as the second local time. And then, synchronizing the second RTC time to the second local time by using a local time synchronization instruction provided by the Linux operating system and a first script which is configured in advance, so as to obtain the synchronized second local time. And finally, carrying out difference value operation on the synchronized second local time and Beijing time at the second time point through a pre-configured first script to obtain a calculation result, forming a standard file by the result, and printing the standard file on a screen, wherein the calculation result is the RTC time offset value.
In some embodiments, the execution body has stored locally a preconfigured first script and second script. If the server to be tested is a local server, the execution main body runs a first script which is configured in advance to execute the RTC clock offset test step, namely, firstly, the local time of the server to be tested at a first time point is obtained, and the time and Beijing time are synchronized to obtain the synchronized first local time. And then, acquiring the RTC time of the local server at the first time point, and synchronizing the RTC time to the first local time to obtain the synchronized first RTC time. And then, after the set target duration is passed, acquiring the RTC time and the local time of the local server at a second time point, and synchronizing the second RTC time to the second local time to obtain the synchronized second local time. And finally, calculating the difference value between the synchronized second local time and the Beijing time of the second time point through a pre-configured first script to obtain an RTC time offset value, and printing the RTC time offset value to form a standard file to a screen. 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 beginning and end of the test. The synchronized time refers to the local time and RTC time synchronized with the beijing time. The local time is the current time of the time zone set by the server system to be measured. Beijing time is the national standard time adopted by the national world and is the international time zone, namely the east-eighth time zone. Synchronizing the first local time is the time after synchronizing the first local time with the Beijing time when the test starts. Script is an extension of batch files, a program that is saved in plain text, and can be typically invoked and executed temporarily by an application. The RTC time synchronization instruction is to synchronize the local time to the RTC time. Synchronizing the first RTC time is when the test starts, and the first RTC time is synchronized with the beijing time at the first time point. 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 identical. 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 at which the test ends. The local time synchronization instruction is to synchronize the RTC time to the local time. Synchronizing the second local time is the time after synchronizing the second RTC time with the second local time at the end of the test. The RTC time offset value is the test result obtained by the RTC clock offset test.
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 server determines the local time of the first time point as the first local time at the first time point, wherein the local time of the first time point is 2024-10-1412:01:00.000, the Beijing time of the first time point is 2024-10-1412:00:00.000, the executing main body executes a preconfigured first script to synchronize the first local time with the Beijing time of the first time point to obtain a synchronized first local time, and 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 to be the first RTC time, namely 2024-10-1412:02:00.000. The execution main body runs an RTC time synchronization instruction provided by a Linux operating system and a first script which is configured in advance, and synchronizes the first RTC time with the synchronous first local time to obtain synchronous first RTC time, wherein the synchronous first RTC time is 2024-10-1412:00:00.000. To this end, the value of the synchronized first local time and the value of the synchronized first RTC time are both consistent with the Beijing time 2024-10-1412:00:00.000 at the first time point. After an hour, the Beijing time at the second time point is 2024-10-1413:00:00.000, the RTC time of the local server at the second time point is determined to be the second RTC time, the second RTC time is 2024-10-1413:00:01.000, the local time of the local server at the second time point is determined to be the second local time, a local time synchronization instruction provided by a Linux operating system and a first script configured in advance are executed, the second RTC time is synchronized to the second local time, and the synchronized second local time is obtained, and at the moment, the synchronized second local time is 2024-10-1413:00:01.000. The execution main body runs a first script which is configured in advance, performs difference value operation on Beijing time synchronizing the second local time and the second time point to obtain a calculation result which is 1 second, the calculation result is an RTC time offset value, the calculation result is stored as a standard file, and the standard file is printed on a screen. The standard file format printed to the screen in this example may be "calculate RTC clock offset value [ '+0.100000', 'sec' ].
Step 103, if the server to be tested is a remote server, running a second script which is pre-configured, popping up a remote login information input window to receive remote login information input by a user, establishing a secure shell protocol ssh connection with the remote server according to the remote login information corresponding to the remote server, executing an RTC clock offset test step to obtain an RTC time offset value of the remote server, forming a standard file by the RTC time offset value, and printing the standard file to a screen.
In some embodiments, if the server to be tested is a remote server, the executing body establishes ssh connection with the remote server, and executes the RTC clock offset test step to obtain an 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. The client runs a second script which is pre-configured, pops up a remote login information input window, prompts a user to input remote login information, inputs corresponding remote login information through the remote login information input window, and establishes ssh connection with a remote server if the remote login information input by the user is correct. As an example, the telnet information contains an OS IP address, an OS user name, an OS user password. After the connection is established, the client executes an RTC clock offset testing step, the obtained RTC time offset value of the remote server is stored as a standard file, and the standard file is printed on a screen of the client. The standard file format in this example may be "calculate RTC clock offset value [ '+0.100000', 'sec' ]. Wherein, the remote server refers to a computer server which is accessed and managed remotely through the internet or other networks, can run at a remote place, and a user can connect and access resources and services of the server by using the terminal device at any place. ssh is a relatively reliable protocol that provides security specifically for telnet sessions and other network services.
In these embodiments, by improving the RTC clock offset test method, the accuracy of the test results is improved. In particular, all times are synchronized at the beginning of the test and any time synchronization operations are avoided during the test. And after the test is finished, automatically acquiring Beijing time, and synchronizing the acquired RTC time to the local time of the server to calculate the difference between the Beijing time and the local time, so as to obtain the RTC time offset value. The conventional method may generate a larger error when directly calculating the difference between the RTC time and the beijing time, and the error can be significantly reduced by calculating the difference between the synchronized local time and the beijing time. In addition, the automatic acquisition of the test time data is more efficient and accurate than the manual acquisition, so that the acquisition efficiency and accuracy of the test data are improved, error fluctuation caused by manual operation is avoided, and the test result is more reliable.
In some embodiments, in order to further solve the second technical problem described in the background section, that is, "in the prior art, a uniform calibration interval duration is generally adopted for different servers, for example, 24 hours, and this fixing scheme cannot meet the personalized requirements of different servers, in addition, in the prior art, an effective RTC module failure analysis method is lacking, so that potential problems cannot be identified and solved in time", in some embodiments of the present invention, an RTC clock offset test method under a Linux operating system further includes:
determining an offset level of a server to be tested according to the RTC time offset value, and inquiring standard calibration interval duration corresponding to the offset level in a pre-configured calibration interval duration table according to the offset level.
In some embodiments, first, a current RTC time offset value is obtained from a server to be tested, and the obtained RTC time offset value is compared with a preset offset standard, and classified into different offset levels. The offset standard refers to a preset acceptance range of RTC time offset, and is used for evaluating the time offset condition of the server to be tested, the offset quantity refers to a current RTC time offset value obtained from the server to be tested, the current RTC time offset value represents the actual time offset degree, and the offset levels can be divided into a plurality of levels according to the offset quantity, such as slight offset, medium offset and serious offset. And then, in a pre-configured calibration interval duration table, inquiring the corresponding standard calibration interval duration according to the determined offset level. For example, a slight offset may correspond to a calibration every 48 hours, a medium offset corresponds to a calibration every 24 hours, while a severe offset may require a calibration every 12 hours.
Step two, obtaining a time precision requirement level of the server to be tested, determining an adjustment coefficient corresponding to the time precision 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 comprises a calibration time point and a calibration time difference.
In some embodiments, first, a time accuracy requirement level is determined according to the application running on the server under test and its specific requirements for time accuracy. Then, a mapping relationship is defined, and different time precision requirement levels (such as high, medium and low) are associated with corresponding adjustment coefficients. This mapping may be stored in a configuration table or dictionary for quick look-up of the system at run-time, e.g., 0.5 for high-precision demand (e.g., microsecond) adjustment, 1.0 for medium-precision demand (e.g., millisecond) adjustment, 2.0 for low-precision demand (e.g., second) adjustment, etc. Generating a target calibration interval duration according to the standard calibration interval duration and the adjustment coefficient queried in the first step, wherein the specific calculation mode can be that the standard calibration interval duration and the adjustment coefficient are multiplied. For example, if the standard calibration interval duration is 24 hours and the adjustment factor is 1.5, the target calibration interval duration is 24 hours times 1.5, i.e., 36 hours. And then, the target calibration interval duration is sent to a server to be tested, so that the server performs time calibration according to the target calibration interval duration, and after each time of time calibration, the server generates a calibration record which comprises a calibration time point and a calibration time difference. The calibration time point is a specific timestamp when the time calibration operation is performed, records the time when the calibration operation starts or ends, is usually expressed in a format of date and time, for example, if the calibration operation is performed at 10 am of 5.11.2024, the calibration time point will be recorded as "2024-11-0510:00:00", and the calibration time difference refers to the difference between the RTC time of the server to be tested and the standard time in the calibration process. The difference may be a positive value or a negative value, if the difference is a positive value, it indicates that the RTC time of the server to be tested is faster than the standard time, i.e. the current RTC time exceeds the standard time, and if the difference is a negative value, it indicates that the RTC time of the server to be tested is slower than the standard time, i.e. 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 for storing, managing and retrieving calibration records.
The method comprises the steps of obtaining a calibration record set in a target historical time period from a database, calculating a calibration time difference change trend corresponding to the target historical time period according to the calibration record set, generating first state information representing that the offset of a server to be tested is in a stable state if the calibration time difference change trend is stable, generating second state information representing that the offset of the server to be tested is in an unstable state if the calibration time difference change trend is large, and generating adjustment information aiming at the target calibration interval duration or RTC module repair prompt information aiming at the server to be tested according to the second state information.
In some embodiments, first, a calibration record set in a target historical time period is obtained from a database, and a calibration time difference variation trend in the target historical time period is calculated according to each calibration record in the calibration record set, wherein the calibration time difference variation trend can be stable or larger. And if the variation trend of the calibration time difference is stable, generating first state information representing that the offset of the server to be tested is in a stable state. If the change trend of the calibration time difference is larger, generating second state information representing that the offset of the server to be tested is in an unstable state, and generating adjustment information aiming at the target calibration interval duration or RTC module repair prompt information aiming at the server to be tested according to the second state information. The calibration record set refers to a set of calibration records obtained from a database in a specific time period, wherein the records contain detailed information of each calibration operation, such as calibration time points and calibration time differences, the change trend of time offset can be known by analyzing the records, the calibration time difference change trend refers to prompt information generated by a system when the change trend of the calibration time difference is detected to be large and the problem can not be solved by adjusting the calibration time difference time, the change amount of each calibration time difference is calculated after time sequence arrangement, and then the average value of the change amounts is calculated to judge whether the calibration time difference tends to be stable or large, the adjustment information can be a modification suggestion of the target calibration interval time length generated according to the change trend of the calibration time difference, for example, if the change trend of the calibration time difference is large, the system may suggest shortening the calibration interval time length to more frequently reduce the offset, and the prompt information generated by a RTC module for a server to be tested is the prompt information generated by the system when the change trend of the calibration time difference is detected to be large and the calibration interval time length is not adjusted, for example, the RTC module is suggested to be checked or repaired.
In the embodiments, through the personalized calibration interval duration setting and the effective RTC module fault analysis method aiming at different servers, the calibration precision of the RTC clock and the health management capability of the modules are obviously improved. According to the actual offset level and time precision requirement of the servers, the calibration interval duration is dynamically adjusted, so that each server can maintain optimal time precision in a specific environment. Meanwhile, potential faults of the RTC module can be timely identified by combining trend analysis of the calibration records, stable operation of the system is ensured, the system can generate information representing the state of the server by collecting and analyzing the calibration records, and the information is regulated or repaired when necessary, so that data errors and information loss risks caused by time deviation are reduced, and the overall production efficiency and the system reliability are improved.
In some embodiments, in order to further solve the third technical problem described in the background section, that is, "the application installation mode in the prior art does not judge that the program needs to be directly installed on time precision, ignoring the difference of the application needs to be on time precision, which may cause a time error occurring in running to affect the application performance and the data accuracy", in some embodiments of the present invention, an RTC clock offset test method under a Linux operating system further includes:
Step one, a pre-configured time precision lookup table is obtained, wherein the time precision lookup table comprises a plurality of application categories and time precision requirement sub-levels corresponding to each application category.
In some embodiments, the execution body queries a locally stored time precision lookup table that contains a plurality of application categories, each application category corresponding to one or more time precision requirement sub-levels. Where application categories refer to categorizing different applications into categories according to their functionality and characteristics, for example, application categories may include financial applications, gaming applications, real-time communication applications, and the like. The time precision lookup table is a pre-configured data structure for storing different application categories and corresponding time precision requirement sub-levels thereof;
Determining a time precision requirement level of a server to be tested as a reference time precision requirement level, determining an application program list of the server to be tested, wherein the application program list comprises application program names and application categories corresponding to the application program names, inquiring actual time precision requirement sub-levels corresponding to each application program name from a time precision inquiry table, updating the actual time precision requirement sub-levels into the application program list to obtain an updated application program list, and transmitting the updated application program list, the time precision inquiry table and the reference time precision requirement level to the server to be tested so as to execute subsequent operations.
In some embodiments, first, a time precision requirement level of a server to be tested is determined as a reference time precision requirement level, and a currently installed application program list is obtained from the server to be tested, wherein the list comprises a name of each application program and a corresponding application category. And then, inquiring the actual time precision requirement sub-level corresponding to each application program name from the time precision inquiry table, and updating the actual time precision requirement sub-levels into the application program list to form an updated application program list. And finally, the updated application program list, the time precision lookup table and the reference time precision requirement level are sent to the server to be tested so that the server can execute subsequent operations according to the information when the application program is installed. The reference time precision requirement level refers to the minimum time precision standard required by the server to be tested under a specific environment, and is generally a reference value set according to the actual application requirement and the system performance requirement of the server, and the determination of the level helps to ensure that the server can meet the time precision requirement of all installed application programs in the running process, and avoid performance degradation or data errors caused by insufficient time precision.
And thirdly, when a new application program installation request is detected, determining the application type of the new application program, inquiring in a time precision inquiry table according to the application type of the new application program to obtain an actual time precision requirement sub-level corresponding to the new application program, and allowing the new application program to be installed if the actual time precision requirement sub-level is lower than a reference time precision requirement level.
In some embodiments, when a system of a server to be tested detects a request for installing a new application program, an application type of the new application program related to the request is identified, and is queried in a time precision query table according to the application type of the new application program, so as to obtain an actual time precision requirement sub-level corresponding to the new application program, the actual time precision requirement sub-level is compared with a preset reference time precision requirement level, and if the actual requirement is found to be lower than the reference level, the installation of the application program is allowed.
And step four, if the actual time precision requirement sub-level is higher than the reference time precision requirement level, displaying time error risk prompt information and a user instruction input control through a popup window, wherein the time error risk prompt information is used for prompting that the time error risk exists in the running process of the new application program, the user instruction input control is used for receiving a user instruction input by a user aiming at the time error risk prompt information, and the user instruction characterizes neglecting the risk or stopping installation.
In some embodiments, when the system of the server under test detects that the actual time precision requirement sub-level of the new application is higher than the reference time precision requirement level, it indicates that the application may be at a greater risk of time errors during operation. At this time, the execution body may display time error risk prompt information to the user through a popup window, so as to inform the user that the application program may not normally run in the current time precision environment, and the current time precision may affect the performance and the data accuracy of the application program. At the same time, a control for receiving user instruction input is also provided in the popup window, so that the user can respond to the risk prompt. The control commands include ignore risk and stop installation. If the received instruction is neglect risk, continuing to install the application program, and if the received instruction is stop to install, ending the installation of the program.
And fifthly, if the user instruction characterizes neglect risk, determining an application program name with the highest time precision requirement sub-level in the updated application program list as a reference application program name, comparing the actual time precision requirement sub-level with the time precision requirement sub-level corresponding to the reference application program name, and if the actual time precision requirement sub-level is smaller than or equal to the time precision requirement sub-level corresponding to the reference application program name, allowing a new application program to be installed.
In some embodiments, if the command received by the control that receives the user command input is an ignore risk, then the new application program is continuously installed, and the system identifies the application program with the highest time precision requirement sub-level from the updated application program list, and determines the name of the application program as the reference application program name. This choice of benchmark application name is based on its highest requirement for time accuracy, intended to provide a reliable reference standard for the installation of new applications. The executing host then compares the actual time precision requirement sub-level of the new application with the time precision requirement sub-level corresponding to the reference application name, and allows installation of the new application if the actual time precision requirement sub-level of the new application is found to be less than or equal to the time precision requirement sub-level of the reference application.
In these embodiments, by determining the time accuracy requirements of the program prior to application installation, it is ensured that only applications meeting the preset time accuracy requirements can be installed, thereby effectively reducing the impact of time errors on application performance and data accuracy. The method not only improves the time management capability of the whole system, but also enhances the compatibility among different applications, so that the system can dynamically adjust the time precision standard according to actual demands, ensure that various applications can stably and accurately perform time calculation in the running process, and further improve the system efficiency.
In some embodiments, in order to further solve the fourth technical problem described in the background section, namely, "in the prior art, before the script is run on the server to be tested to perform the RTC clock offset test, command differences existing between different Linux system release boards are not considered, and such differences may cause that in some release board systems, the script cannot be successfully executed, thereby causing test failure. In some embodiments of the present invention, a method for testing RTC clock offset in a Linux operating system further includes:
step one, collecting command differences among release boards of a conventional Linux system, and sorting and storing the command differences to form files locally.
In some embodiments, the executing body collects and collates command differences between common Linux releases (e.g., ubuntu, fedora, debian, centOS, arch Linux, etc.) to form a system command difference information table. The table should contain the correspondence between different commands of the same function under different Linux releases. The Linux system release is an operating system version based on a Linux kernel, different development teams and organizations can modify and customize the Linux system release according to specific requirements and targets, and common Linux release comprises Ubuntu, fedora, debian, centOS, arch Linux and the like.
And step two, judging the type of the server to be tested as a remote or local server.
In some embodiments, the execution body completes the server type judgment through the foregoing step 101, if the server to be tested is a remote server, the required remote login information such as an IP address, a login user name and a password is obtained first, then the remote server is connected by using ssh, after successful login, the subsequent operation is performed, otherwise, the operation is terminated and an error message is returned, and if the server to be tested is a local server, the subsequent step is directly performed.
And thirdly, acquiring server information by using a server command, generating a system information file and storing the system information file to a local place.
In some embodiments, after the execution subject successfully logs in to the server, the execution subject obtains the server information by using a command, including a hostname, an operating system version, a kernel version and a hardware architecture of the current system, stores the hostname, the operating system version, the kernel version and the hardware architecture as a system information table in a directory where a script for performing RTC clock offset test is located, and waits for matching with a system command difference information table. Wherein the server command may be hostnamectl, which is a command line tool for querying and setting up system hostnames and related network configurations, which is part of the system and service manager. Through hostnamectl, the user can view and modify information such as the hostname, operating system version, kernel version, and hardware architecture of the system. This command is typically present in different Linux releases and is relatively consistent in usage, and is therefore very convenient and common in system information acquisition and management. The kernel version refers to a specific version number of the operating system kernel. The kernel is the core part of the operating system and is responsible for managing the interactions between system resources, hardware devices and software processes. Different kernel versions may contain different functional improvements, security repairs, performance optimizations, and hardware support, and a hardware architecture refers to the organization and structure of various hardware components in a computer system, including their connection manner and working mechanism with each other, such as a Central Processing Unit (CPU), a memory (RAM), etc.
And step four, referring to a system command difference information table, comparing the system information table, matching the version of the server system to be tested, and judging whether the command difference exists.
In some embodiments, the execution body extracts the release version information of the specific Linux system 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 a difference command exists in the current system version.
And fifthly, after the matching of the system information table and the system command difference information table of the server to be tested is completed, identifying incompatible commands in the script used for the RTC clock offset test, and replacing the commands.
In some embodiments, after the execution body completes matching of the server system information table to be tested and the system command difference information table, if a difference command is found, a command adapted to the current release is used to replace an incompatible part in a script used for RTC clock offset test, so as to ensure that the script can be normally executed on the current Linux system release.
And step six, after the replacement of incompatible commands in the script used for the RTC clock offset test is completed, confirming that the script is suitable for the current Linux distribution plate, and then continuing to run the script to execute the RTC clock offset test.
In some embodiments, the completion of RTC clock offset testing of steps 102 or 103 described above may be performed by performing the steps described above, with differential command substitution of different systems in the script having been completed.
In the embodiments, by identifying command differences among different Linux release plates, the accuracy and reliability of RTC clock offset test can be remarkably improved, and the test failure risk caused by command incompatibility is reduced, so that the validity and consistency of test results are ensured. The method improves the stability of RTC clock offset test scripts on different release boards of Linux systems, and provides powerful support for accurate management of system time.
The above description is only illustrative of the few preferred embodiments of the present invention and of the principles of the technology employed. It will be appreciated by persons skilled in the art that the scope of the invention referred to in the present invention is not limited to the specific combinations of the technical features described above, but also covers other technical features formed by any combination of the technical features described above or their equivalents without departing from the inventive concept described above. Such as the above-mentioned features and the technical features disclosed in the present invention (but not limited to) having similar functions are replaced with each other.
Claims (5)
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202411566438.6A CN119512316A (en) | 2024-11-05 | 2024-11-05 | A method for testing RTC clock offset under Linux operating system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202411566438.6A CN119512316A (en) | 2024-11-05 | 2024-11-05 | A method for testing RTC clock offset under Linux operating system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN119512316A true CN119512316A (en) | 2025-02-25 |
Family
ID=94652050
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202411566438.6A Pending CN119512316A (en) | 2024-11-05 | 2024-11-05 | A method for testing RTC clock offset under Linux operating system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN119512316A (en) |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6708281B1 (en) * | 2000-07-10 | 2004-03-16 | Advanced Micro Devices, Inc. | Methods for providing estimates of the current time in a computer system including a local time source having one of several possible levels of trust with regard to timekeeping |
| US20200057740A1 (en) * | 2018-08-14 | 2020-02-20 | Inventec (Pudong) Technology Corporation | Remote login method for server subsystem and remote login system |
| CN113377156A (en) * | 2021-07-13 | 2021-09-10 | 北京同方信息安全技术股份有限公司 | RTC (real time clock) accuracy verification method and device |
| CN114489239A (en) * | 2022-01-21 | 2022-05-13 | 国微集团(深圳)有限公司 | Method and device for dynamically calibrating real-time clock |
| CN116388913A (en) * | 2022-12-30 | 2023-07-04 | 上海移柯通信技术股份有限公司 | RTC clock self-calibration method, electronic equipment and storage medium |
| CN118473975A (en) * | 2024-04-29 | 2024-08-09 | 苏州元脑智能科技有限公司 | Diagnostic method, device, equipment and medium of precision time protocol clock server |
-
2024
- 2024-11-05 CN CN202411566438.6A patent/CN119512316A/en active Pending
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6708281B1 (en) * | 2000-07-10 | 2004-03-16 | Advanced Micro Devices, Inc. | Methods for providing estimates of the current time in a computer system including a local time source having one of several possible levels of trust with regard to timekeeping |
| US20200057740A1 (en) * | 2018-08-14 | 2020-02-20 | Inventec (Pudong) Technology Corporation | Remote login method for server subsystem and remote login system |
| CN113377156A (en) * | 2021-07-13 | 2021-09-10 | 北京同方信息安全技术股份有限公司 | RTC (real time clock) accuracy verification method and device |
| CN114489239A (en) * | 2022-01-21 | 2022-05-13 | 国微集团(深圳)有限公司 | Method and device for dynamically calibrating real-time clock |
| CN116388913A (en) * | 2022-12-30 | 2023-07-04 | 上海移柯通信技术股份有限公司 | RTC clock self-calibration method, electronic equipment and storage medium |
| CN118473975A (en) * | 2024-04-29 | 2024-08-09 | 苏州元脑智能科技有限公司 | Diagnostic method, device, equipment and medium of precision time protocol clock server |
Non-Patent Citations (2)
| Title |
|---|
| 何宗键编著: "Windows CE嵌入式系统", 30 September 2006, 北京航空航天大学出版社, pages: 102 - 103 * |
| 韩辉，李孝成，王翾，张荣荣，徐贵洲编: "SylixOS设备驱动程序开发", 31 January 2022, 北京航空航天大学出版社, pages: 164 - 165 * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111736875A (en) | Version update monitoring method, device, device and computer storage medium | |
| US20050022176A1 (en) | Method and apparatus for monitoring compatibility of software combinations | |
| CN112583648B (en) | Intelligent service fault processing method based on DNS | |
| KR20050053657A (en) | Methods and apparatus for root cause identification and problem determination in distributed systems | |
| US7913081B2 (en) | Dynamic certification of components | |
| US20090031174A1 (en) | Server outage data management | |
| US20240118884A1 (en) | Automated deployment method for upgrading client's internal business software systems | |
| WO2017020715A1 (en) | Method and device for monitoring status of cdn node | |
| CN108199901B (en) | Hardware repair report method, system, device, hardware management server and storage medium | |
| CN111698343A (en) | PXE equipment positioning method and device | |
| CN115061885A (en) | Complete machine aging automatic test method and device, electronic equipment and storage medium | |
| CN119512316A (en) | A method for testing RTC clock offset under Linux operating system | |
| EP1684458A1 (en) | A method of calculating broadband access server dhcp user's on-line time | |
| CN116483388A (en) | System filling method, device, equipment and medium based on multiple configuration requirements | |
| CN104811343A (en) | Network detection method and system of peer-to-peer network | |
| CN113377156B (en) | RTC clock accuracy verification method and device | |
| CN119127620A (en) | A method for implementing Prometheus automatic monitoring in a microservice scenario | |
| CN101390337B (en) | Automatic device configuration | |
| CN111506507B (en) | Business service state detection method and device, electronic equipment and storage medium | |
| CN118473975A (en) | Diagnostic method, device, equipment and medium of precision time protocol clock server | |
| CN118467314A (en) | System and method for testing server performance | |
| CN118449895A (en) | Network card pressure measurement method, device, equipment and medium based on network card mode | |
| CN106484460A (en) | The installation method of large-scale storage cluster system in a kind of | |
| CN109286692A (en) | A kind of method of configuration server IPMI static ip address | |
| CN113849328A (en) | Disaster recovery system management method and device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |