Partager via

What is Windows Time Service?

  • Article

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:

  1. The time client makes a request for a timestamp at time t1
  2. The time source receives the request a time t2
  3. The time source sends back a response a time t3
  4. 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.

 Wrap Up

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.

Comments

  • Anonymous
    July 19, 2007
    Nice start. One thing that may be helpful is a list of a couple of quick things and settings that can be done. For example, setting the root DC to an external time source, what settings need to be configured in the registry. Another thing that would be nice is a guess on what to do when you see event 50 or 52 or any other common events. Also, maybe a thought when a problem occurs, maybe it is a w32tm issue or maybe a hardware issue.

  • Anonymous
    July 19, 2007
    The comment has been removed

  • Anonymous
    August 24, 2007
    An interesting article.  But I don't understand the logical step that gets you to "((t4 - t1) - (t3 - t2)) is the clock offset between the two computers". Consider the following scenario: The client's clock is 10 seconds slow. Let's say that T+n means n seconds past midnight. The client makes a request at T+15 by the client's clock (T+25 in reality). The request takes 3 seconds to get to the time source.  It arrives at T+28. The time source sends a reply 1 second later, at T+29. The reply takes 2 seconds to get back to the client.  It arrives at T+31, or T+21 by the client's clock. So t1 is T+15, t2 is T+28, t3 is T+29, t4 is T+21.  ((t4 - t1) - (t3 - t2)) is ((21-15) - (29-28)), which is 5 seconds.  But the client's clock is 10 seconds slow. What am I missing?

  • Anonymous
    August 24, 2007
    Well, the problem here is that I was callous with the copy-and-paste. You might notice that the formula for calculating the offset is the same one for calculating the delay. Yea, right. The correct formula for clock offset is: ((t2 - t1) + (t3 - t4)) / 2 t1 = 00:00:15 (15 seconds after midnight, according to the client's clock) [3 second transmission delay] t2 = 00:00:28 (28 seconds after midnight, according to the server's clock) [1 second processing delay] t3 = 00:00:29 (29 seconds after midnight, according to the server's clock) [2 second transmission delay] t4 = 00:00:21 (21 seconds after midnight, according to the client's clock) ((t2 - t1) + (t3 - t4)) / 2 ((28 - 15) + (29 - 21)) / 2 (13 + 8) / 2 21 / 2 =10.5 Why 10.5 instead of 10? One of the assumptions that NTP makes is the transmission delay is the same in both directions. For argument's sake, I left it the way you described, especially because in the real world assumptions fail all the time. I hope this clears things up. Thanks for catching this occultations.

  • Anonymous
    August 28, 2007
    That's more like it!  I'm interested that NTP assumes the transmission delay is the same in both directions.  It seems quite likely that there would be a systematic bias.  Can NTP do anything about that? I've also got a query about W32time.  I've got a PC here on which W32time has spent a week trying to sync the time, but it keeps on overcorrecting.  If you're interested, and you can let me know your email address, I'll send you some graphs. Cheers, Chris

  • Anonymous
    September 02, 2007
    The issue with transmission delay is that there is no way to detect what the delay is in any one direction since you are dealing with two independent clocks. This is detailed in the NTP RFC linked at the top of the post. If you have questions, you can start by asking them in the technet forums: http://forums.microsoft.com/TechNet/ShowForum.aspx?ForumID=722&SiteID=17 I will see your question there, and it is a better forums to help you with your specific issue.

  • Anonymous
    September 03, 2007
    You wrote that the value controlling when w32time skews or sets is adjustable in the registry (default is 5 min?). Please let us know the registry entries.

  • Anonymous
    September 03, 2007
    The value that you are referring to is the value which Kerberos uses to determine if another machine is too far out of sync with to allow authentication. W32time time skews are a bit more complicated, and will be covered in an upcomming post. If you have questions about Kerberos, try posting a question in the Technet forum linked in my comment above.

  • Anonymous
    September 11, 2007
    I have added a post at http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=2100204&SiteID=17 about W32Time overcorrecting.  I hope you can have a look at it.

  • Anonymous
    July 27, 2012
    Can any one please help me to resolve this time syncronization issue. I have 2 Windows 2008 servers which we want to change the time zone to eastern but every time we reboot the time zone comes back to the default zone (Mountain Time). Can you please help me to fix this problem.

  • Anonymous
    July 27, 2012
    @smakhdoom: Try posting your question here: social.technet.microsoft.com/.../threads

  • Anonymous
    October 30, 2014
    Nice one!