These graphs show the drift graphs collected from an Active Directory server and client over several hours, both machines using the Windows Time Service to set their time. The AD Server was set to get its time from time.nist.gov, and the AD Client used the default Windows Time settings to get its time from the AD Server.

Notes


• Domain Time II Full Client was installed on the machines to provide the graphical data, but set to Test mode so that it did not set the clock. The graphs show the actual variance on the machine from the reference time source - time.nist.gov.
• The Domain Time client wrote a data point to the graph at 10 minute intervals, but this does not mean the Windows Time Service updated its time that often. There's no way to know how often Windows Time actually set the time; it might correspond to the overall large jumps seen occasionally in the data, but then again it might not.
• These machines were not under load, or on a busy network, or located across a WAN with high latency. Real-world results under those conditions will almost certainly be worse than the results shown here. In particular, even moderate activity on the machine can cause dramatic clock drift far in excess of the drift seen on these test systems.
• See the Graphs Page for an explanation of the various graph elements.

Active Directory Server Windows 2000 running on a Dual-Pentium III 500 Mhz system Windows Time Service, Time source: time.nist.gov	Active Directory Client Windows XP Pro running on a Pentium 4 2.8 Mhz Windows Time Service, Time source: AD Server
During the five-hour period shown on this graph (shortly after startup), the time service appears to not be setting the time at all, as the clock steadily drifts toward 1/4 second of error.	During the same five-hour period on the client (shortly after startup), the client's time drifts over 1/2 second of error(!) then appears to correct after several hours and start drifting in the opposite direction.
This five-hour period shows that the server appears to have set its clock, however it continues to drift uncorrected for several hours at a time.	The client also appears to have set its clock, however, notice the difference in time scale on this graph from the server graph. The client is an order of magnitude off and drifting farther away.
In this graph, we see the server once again drifting for several hours, but eventually setting its clock.	However, the client continues to drift uncorrected to 1/4 second of error and beyond. Note the difference in graph scale has increased again.

Performance of the Same Machines Running Domain Time II

---

The last two graphs show the drift graphs collected from the same Active Directory server and client machines as above over several hours, both machines using Domain Time II to set their time. The AD Server was set to get its time from time.nist.gov, and the AD Client used the default Domain Time II settings to get its time from the AD Server.

Notes


• Domain Time II Server v3.1 was installed on the Active Directory Server and set to get its time from time.nist.gov.
• Domain Time II Full Client v3.1 was installed on the Active Directory Client machine and set to get its time from the AD Server.

Active Directory Server Windows 2000 running on a Dual-Pentium III 500 Mhz system Domain Time II Server, Time source: time.nist.gov	Active Directory Client Windows XP Pro running on a Pentium 4 2.8 Mhz Domain Time II Full Client, Time source: AD Server
Five hours of time sync measurements on the Active Directory Server. The contrast between the Windows Time Service and Domain Time II couldn't be clearer, could it?	The same five-hour period on the client.