What is Windows Time Service?
Welcome to the Windows Time Service blog. This blog is here to answer some of the questions about the service and show off some of the useful features that it has. Every week, I will try to cover a new topic surrounding Windows Time Service (w32time for short). If anyone has any requests/suggestions for topics, please feel free to let me know. This blog is for you.
So what is Windows Time Service?
In short, it is a Windows service that keeps your computer clock accurate. Of course, the "how" is much more interesting than the "why", but for the sake of being the initial post, I will start with why time service exists; and for that, we require a bit of history. NOTE:Most of the information about the history of w32time comes from previous knowledge, which is not very extensive. If you find a mistake, please let me know.
In the days of Windows NT 4.0 and prior, there actually wasn't NTP support, but rather SNTP. This was an initial version of the time service that focused on basic time synchronization (I believe the service was called TimeServ). SNTP doesn't support most of the features of the full NTP protocol, which would be needed in future versions of Windows.
Windows 2000 brought about a wealth of new features, including Kerberos authentication. As part of the Kerberos protocol (section 1.6, 4th bullet of the RFC), computers using Kerberos authentication need to have clocks that are "loosely synchronized", which is defined as 5 minutes by default. To meet this need, SNTP was abandoned and w32time was born. From Windows 2003 though Vista/Windows Server 2008, w32time has been upgraded & retrofitted to support more features, differing environments, and basically meet whatever needs customers and other internal components have.
How does Windows Time Service work?
Well, without getting into some of the messy details, w32time communicates with other computers in your network to keep the time on your local computer accurate. The overreaching goal is to keep your local clock in step with a remote clock. In this way, w32time is synchronizing your computer's clock to that of your time source. (Keep in mind that most of this information can also found in the NTP v3.0 RFC, which w32time is based on). This is done by sampling the time on a remote system (known as the time source). The communication between a time client and a time source looks something like this:
- The time client makes a request for a timestamp at time t1
- The time source receives the request a time t2
- The time source sends back a response a time t3
- The time client receives the response a time t4
This is the fundamental interaction between a time client and a time source. The astute reader would first ask the following question:
Well, if the 2 computers are not currently synchronized (which is the point of this communication in the first place), then how can those time values (t1 - t4) be useful at all?
This is a great question because it demonstrates the ingenious design of NTP to be computer independent. Without making assumptions about the relationship of the time source and time client, we can make these initial observations:
- (t4 - t1) is the total time that is took for the time source to send out a request and get back a response (transit time)
- (t3 - t2) is the total time that the time source spent processing the request (processing time)
- ((t4 - t1) - (t3 - t2)) is the total transit time of the request (transit time - processing time)
Using this, we can make the following additional observation:
- ((t2 - t1) + (t3 - t4)) / 2 is the clock offset between the two computers
[EDIT: The above formula has been corrected. Thanks occulations]
Now that we have the clock offset, we can start to correct the clock on the local computer (the time client). Correcting the time on a computer can be done in two ways: skewing and setting. If the time difference is small enough*, we can adjust the clock gradually over time. However, if the time difference is too large* (such as hours or days), it is better to simply set the local clock to the desired time.
* The concept of "too large" or "too small" is relative. These values are adjustable in the registry so that you can control when w32time skews, sets or does nothing at all.
The relationship between w32time and local clock (yes, they are two distinct entities) is complicated and will be explained in a later post.
Time source selection
Aside from how the service determines the time difference, the next most common question is: How does w32time choose a time source (known as a peer)? The service can operate in one of two possible modes:
- NTP (as defined in the original RFC)
- NT5DS (using domain lookup mechanisms)
The NTP mode is straight-forward: Try to sync with the peer specified. If you can't, wait until you can. This is the mode that non-domain joined computers use. The DNS name or IP address of the peer can be changed in the registry, but it comes as 'time.windows.com' by default. Microsoft hosts its own NTP server, which is how your computer gets correct time "out of the box".
Domain joined computers utilize the NT5DS mode. This mode uses netlogon API calls to find an eligible peer to sync with. Because domains can become both large and deep, and w32time needs to operate in an optimal fashion either way, there is a complex algorithm that is used to find a peer. I will be covering this later in a seperate post (since it is such a large and involved topic), but you can find a reasonable explaination at TechNet for Windows Server 2003. Here is the quick overview:
- Computers sync with DCs, preferably from their own site/domain
- DC sync with local PDC, but will go out of site/domain if needed
- PDCs sync with other PDC, but possible DCs higher up in the forest if needed
At the top of the forest (at the root domain), there needs to be either a local time source or a link to an external peer that provides reliable time data. Again, this really needs a long discussion to make proper sense, but in essence the domain needs to get its time data from somewhere. The w32time service is responsible for distributing the time throughout the domain, but it needs to go to another source to get the data to distribute in the first place.
This should give you a brief look at the Windows Time Service and how it works. If you have topic ideas, please let me know. I'm only one man, and this isn't the Shell Blog. I have a list (and it is growing) for future topics, but if the community feels that one or more issues are more important, I will do my best to cover them first. As I said in the beginning, this blog is for you.