Microsoft's official enterprise support blog for AD DS and more
Hello there. I’m Bob Drake from Microsoft’s Directory Services Team. Quite often we get inquiries on how to configure networks for high accuracy time needs. In some cases, customers want the time accurate down to the second. There are a lot of occasions where high accuracy is imperative (applications in the banking industry, air traffic control, and weather to name a few), so the purpose of this blog is to explain what the Windows Time service (W32Time) was designed to do, and why we recommend using other solutions if you require high accuracy time for your environment. Before we go any further, we need to take a look at RFC 1305 “Network Time Protocol (Version 3) Specification, Implementation and Analysis. It has plenty of useful information, including:
So it appears that NTP can be accurate even to the nanoseconds, although there will be a lot of work to make it that accurate. Now this is where Microsoft comes into the scenario…….In our Windows Time Service Technical Reference we discuss stratums and how higher stratums become less accurate:
“The degree to which a computer’s time is accurate is called a stratum. The most accurate time source on a network (such as a hardware clock) occupies the lowest stratum level, or stratum one. This accurate time source is called a reference clock. An NTP server that acquires its time directly from a reference clock occupies a stratum that is one level higher than that of the reference clock. Resources that acquire time from the NTP server are two steps away from the reference clock, and therefore occupy a stratum that is two higher than the most accurate time source, and so on. ‘As a computer’s stratum number increases, the time on its system clock may become less accurate’. Therefore, the stratum level of any computer is an indicator of how closely that computer is synchronized with the most accurate time source.”
Now we need to discuss W32Time and its inception. With the introduction to W32Time, the W32Time.dll was developed for Windows 2000 and up to support a specification by the Kerberos V5 authentication protocol that require clocks on a network to be “synchronized” . I’ll save you from the very long (but interesting) read on RFC 1510 Kerberos documentation and pull out what is relevant.
• RFC 1510: “If the local (server) time and the client time in the authenticator differ by more than the allowable clock skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW error is returned.”
In short, W32time was created to assist computers to be equal to or less than five minutes (which is configurable) of each other for authentication purposes based off the Kerberos requirements. We do this to make replay attacks (where some malicious person attempts to capture and alter Kerberos packets between the client and server) more difficult. So where is it configured you ask? Here is the location in a policy:
This finally brings us to KB article 939322:
“Support boundary to configure the Windows Time service for high accuracy environments”
“We do not guarantee and we do not support the accuracy of the W32Time service between nodes on a network. The W32Time service is not a full-featured NTP solution that meets time-sensitive application needs. The W32Time service is primarily designed to do the following:
The W32Time service cannot reliably maintain sync time to the range of 1 to 2 seconds. Such tolerances are outside the design specification of the W32Time service.”
But Microsoft does give reference on third-party publishers of time and frequency software that can assist with those extreme high accuracy needs (NOTE: These are not Microsoft related or endorsed- just referenced)
Last but not least, if you can afford it and need even more accurate time, look for this 10,000 Year Clock :).
Look for more information on configuring and troubleshooting W32time in a future blog post.
- Bob Drake
PingBack from http://ghillie-suits.info/?p=40823
Spect.le DS Team,
anyway, wich are best w32Time registry settings to get most high accuracy possible?
2 seconds instead of 4 could be a good result for us.
We actually don't like to get into specifics with regards to high accuracy time, because we flat out cannot guarantee they will stay consistent using the x86/x64 motherboards real-time clock. All we will guarantee from a support standpoint is 300 seconds, so that Kerberos will function.
If you are really looking for that 1-2 second kind of accuracy, we always recommend you invest in replacement hardware clocks that override the PC's RTC and give you extreme accuracy (think nanoseconds).
That being said, you can look over http://technet2.microsoft.com/windowsserver/en/library/b43a025f-cce2-4c82-b3ea-3b95d482db3a1033.mspx for a complete list of the time registry settings and how they can be used to try and get time closer to a few seconds of drift.
Once again I would have to point to an alternate time solution for your needs. W32time was not designed to maintain that degreee of accuracy.
If you wanted to test registry keys since an alternate method could not be accomplished you can test adjusting the keys noted (again this is not guaranteed):
Taken from http://technet2.microsoft.com/WindowsServer/en/library/b43a025f-cce2-4c82-b3ea-3b95d482db3a1033.mspx?mfr=true
Windows XP and Windows Server 2003
This entry controls the rate at which the phase error is corrected. Specifying a small value corrects the phase error quickly, but might cause the clock to become unstable. If the value is too large, it takes a longer time to correct the phase error.
The default value on domain members is 1. The default value on stand-alone clients and servers is 7.
This entry specifies the smallest interval, in log2 seconds, allowed for the system polling interval. Note that while a system does not request samples more frequently than this, a provider can produce samples at times other than the scheduled interval. The default value for domain controllers is 6. The default value for domain members is 10. The default value for stand-alone clients and servers is 10.
This entry specifies the largest interval, in log2 seconds, allowed for the system polling interval. Note that while a system must poll according to the scheduled interval, a provider can refuse to produce samples when requested to do so. The default value for domain controllers is 10. The default value for domain members is 15. The default value for stand-alone clients and servers is 15.
This entry specifies the number of clock ticks between phase correction adjustments. The default value for domain controllers is 100. The default value for domain members is 30,000. The default value for stand-alone clients and servers is 360,000.
More than any other, the most often asked question of the Windows Time Service is "How do I configure
My daughter Alyssa and I play a game…well she might not consider it a game but she is constantly
Thanks a lot for taking the time to answer this questions. We experience quite a lot of inquiries from Windows users exactly asking the same question.
Our standard answer exactly matches your reply (Kerberos, better than 5 min) although we sometimes see better results with W32time and our time server appliances. For customers requiring a better accuracy, we offer a Windows port of Dave Mills' reference implementation of NTP, i.e. the very same code that runs on almost every Unix-based OS around, and that does a very good job (better than 100ms), although we still experience problems with Vista (working on that).
The only drawback with using NTP on Windows instead of W32time is the fact that automatic time synchronization does not work, i.e. the workstations do not automatically determine the domain controller as a time server, most probably because the NTP service does not register itself in the directory as a time source.
If someone from Microsoft would be willing to spend some time on this and assist us (the NTP opensource project AKA ntp.org), please contact me at heiko dot gerstung at meinberg dot de !
Again, thanks for your article, a good reference to point customers to!