High Accuracy W32time Requirements

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:

• “The accuracies achievable by NTP depend strongly on the precision of the local-clock hardware and stringent control of device and process latencies.”….
• “With current technology and available radio clocks, single-sample accuracies in the order of a millisecond can be achieved at the network interface of a primary server. Accuracies of this order require special care in the design and implementation of the operating system and the local-clock mechanism,”
• “The authentication procedures described in Appendix C represent one mechanism to enforce this; however, the encryption algorithms can be quite CPU-intensive and can seriously degrade accuracy, unless precautions such as mentioned in the description of the transmit procedure are taken.”

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:

• Make the Kerberos version 5 authentication protocol work.
• Provide loose sync time for client computers.

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)

• https://tf.nist.gov/general/softwarelist.htm for software.
• https://tf.nist.gov/timefreq/general/receiverlist.htm  for hardware.

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

Comments

• Anonymous
  October 28, 2007
  PingBack from http://ghillie-suits.info/?p=40823

• Anonymous
  November 16, 2007
  The comment has been removed

• Anonymous
  November 16, 2007
  The comment has been removed

• Anonymous
  November 27, 2007
  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): PhaseCorrectRate   MinPollInterval   MaxPollInterval   UpdateInterval     Taken from http://technet2.microsoft.com/WindowsServer/en/library/b43a025f-cce2-4c82-b3ea-3b95d482db3a1033.mspx?mfr=true   PhaseCorrectRate Registry path HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeConfig Version 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. MinPollInterval Registry path HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeConfig Version Windows XP and Windows Server 2003 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. MaxPollInterval Registry path HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeConfig Version Windows XP and Windows Server 2003 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. UpdateInterval Registry path HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeConfig Version Windows XP and Windows Server 2003 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.

• Bob

• Anonymous
  June 10, 2008
  More than any other, the most often asked question of the Windows Time Service is "How do I configure

• Anonymous
  October 10, 2008
  My daughter Alyssa and I play a game…well she might not consider it a game but she is constantly 

• Anonymous
  April 02, 2009
  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! Regards,  Heiko