Implement a continuous update and high precision time supply for Windows

This article assumes that you are familiar with the C + + and Win32 APIs

Profile

The time stamp (Timestamp) obtained from Windows NT has a maximum accuracy of 10 to 15 milliseconds depending on the hardware you are using. However, sometimes when you need time to label frequent events, getting higher accuracy is more satisfying. For example, what if you want to deal with threads, or do some other task at intervals of not less than 10 milliseconds? For better accuracy, the recommended approach involves using performance counters and system time to compute a smaller time increment. However, the use of performance counter technology has its own problems. This paper will reveal a feasible way to overcome the inherent limitations of the method.

Why are you interested in getting a system time that is less than 1 milliseconds in accuracy? During my work, I found it necessary to determine the order in which the events raised by different threads in my process were executed. These events also need to be associated with absolute time, but note that the actual precision of the system time will not exceed 10 millisecond granularity.

In the later part of this article, I will explain the limitations of the system's time precision, the steps to resolve it, and some general flaws. The implementation of the example program can be downloaded from the link at the beginning of this article. Are the source code for these files in Visual C + +? 7.1 and Windows? XP Professional Edition to write tests. When writing this article, I frequently refer to the Windows NT® operating system family (Windows NT 4.0, Windows 2000, or Windows XP) product, not to a specific version. The Win32 used in this article? parameter types and usage of APIs, see MSDN library/platform SDK documentation.

Who on Earth has such a demand?

I recently searched the Internet for "Windows NT millisecond time resolution" as a keyword, and got more than 400 results to meet the conditions. Most of them discuss how to get a system time that is above 10 milliseconds, or how to keep a thread dormant for less than 10 milliseconds. In this article I will focus on why it is so difficult to get a system time that is above 10 millisecond precision. You may think that using the GetSystemTime API is an easy fix, and this API function returns a SYSTEMTIME structure that contains a wmilliseconds domain, which is said to hold the current millisecond time in the MSDN documentation. But it's not really as simple as that. What about the accuracy of getting 100 nanoseconds with Getsystemtimeasfiletime? Let's start with a little experiment: try to get the system time repeatedly, format it and output it to the screen (see Figure 1).

My goal is not nanosecond, but only millisecond precision, which should be able to be judged from the SYSTEMTIME structure. Let's look at the output:

20:12:23.479
20:12:23.479
20:12:23.494
20:12:23.494
[...有很多被移去了...]
20:12:23.494
20:12:23.509
20:12:23.509
20:12:23.509
...

As you can see, the best I could get is 15 milliseconds, which is the length of the Windows NT clock cycle. Windows NT updates the system time every past clock cycle. The Windows NT scheduler will also suddenly start and may choose a new thread to execute. For more information on this, see the third edition of Inside Windows 2000 (Microsoft press®, 2000), the authors are David Solomon and Mark Russinovich.

If you run the code I've just shown, you may see that the time is about to be updated every 10 milliseconds. If so, it may mean that you are running Windows NT on a single-processor machine with a clock cycle typically 10 milliseconds. As you can see, in this approach, the system time is not updated fast enough to be a technology for me. Let's try to find a solution here.

The initial attempt

When you ask how to get a better system time than 10 milliseconds, you may get the answer to the following: Use performance counters and synchronize performance counter values with real-time changes in system time. These values are combined to compute an extremely high precision of the current time. Figure 2 shows the implementation method.

The performance counter is a high-precision hardware counter that can measure a short period of time with high precision and low overhead. I am constantly synchronizing the performance counter values and corresponding system times in a compact loop, waiting for system time to change. When the system time changes, I will save the value of the counter and the system time.

Using these two values as a reference, it is possible to compute a high-precision current system time (see the Get_time in Figure 2 for details), and look at the results:

...
21:23:22.296
21:23:22.297
21:23:22.297
21:23:22.298
21:23:22.298
21:23:22.299
21:23:22.300
21:23:22.300
21:23:22.301
21:23:22.301
21:23:22.302
21:23:22.302
21:23:22.303
...

Although it looks very successful, there are several problems with this implementation: synchronous implementation (a good reason for the function being named "Simplistic_synchronize"), the frequency of queryperformancefrequency reporting, and the lack of protection for system time changes. In the following sections, we will consider some possible improvements to these issues.