Settings on this page control how often time checks are performed when querying servers for the time (if using normal NTP or DT2 protocols) or
how often samples are coalesced for statistics/alerting if using PTP.
Note:
If Domain Time Server on this machine is set as a Slave server, this page will not appear since Slaves inherit their timing settings from the Master server.
See Domain Roles for more information on Master, Slave, and Independent Server roles.
Timings for broadcast NTP or DT2 are set on the Serve the Time property page.
The settings on this page do not apply if you are using the Broadcast/Multicast method of obtaining network time.
If you see the Group Policy applied indicator in the lower-left corner of the applet,
there are settings on this page that are being overridden by an Active Directory Group Policy. Settings controlled by policy may be greyed-out or you may be otherwise prevented from making a change here.
See the Active Directory page for more information on using Group Policies.
Finding the "Sweet Spot"
The system clock on every machine runs at a different rate because of differences in operating system, applications, hardware, and environment. Even
when well-managed by a time program such as Domain Time, the clock will always eventually drift either slower or faster than the actual time,
Since the clock can't be made to run at a perfect rate, it is necessary to correct it when it drifts. In general, the more often you can
correct the clock, the more accurate it will be. The corollary to this is that the worse the clock drifts, the more often it must be corrected.
The goal of time correction is to synchronize often enough to keep the system clock within your accuracy target but not so often as to generate excessive
network traffic or system overhead. We refer to this ideal rate as the synchronization sweet spot.
In many cases, Domain Time does a very good job of automatically discovering the sweet spot (using the Variable scheduling method).
It also, by default, uses an overall clock-rate adjustment, to train the clock to run more accurately over time. However, the more accurate you need the clock to be
(or the worse the clock itself is), the more difficult it is for these algorithms to make correct decisions to compensate correctly for drift.
In those cases, you will need to manually set a Fixed synchronization rate, using trial-and-error to find the sweet spot. You
may want to start with a reasonable rate such as 5 minutes, and then if that's not sufficient, try every 3 minutes, then 1 minute, etc. On machines with
highly-variable drift, you may also need to disable Domain Time's long-term clock adjustment function (see the Correction Reduction section of the Clock Control page).
Even with severe correction, some systems simply cannot be disciplined enough for every purpose. For example, virtual machines are often too inherently poor at timekeeping to be used for time-critical systems and you must change to physical hardware to achieve your desired accuracy.
However, in most cases, you will usually be able to find the sweet spot for your systems by adjusting the synchronization rate appropriately.
There are two scheduling options for determining how often Domain Time checks the time/reports statistics:
Variable - check as often as needed to maintain approximately milliseconds sync with server
When this option is selected, Domain Time will automatically adjust how often it synchronizes with time sources to attempt to keep the clock within the threshold limit you set.
The wait period between time checks is called the window size. You can see the window size Domain Time is currently using by examining the Text Log.
Domain Time will adjust the window size based on how accurate previous time checks have been. If previous time corrections have been small the window size will be increased, and vice versa. The range of adjustment
for the window size is between 15 seconds to 2 hours. On most machines, it will average between 10 - 30 minutes.
The Variable scheduling method is intended for use on machines with relatively constant clock drift and moderate accuracy requirements (where the acceptable tolerance for clock drift is more than ~25ms).
This method is a good for general-purpose use, primarily on Clients, since it strikes a good balance between maintaining the target accuracy while minimizing network traffic.
Variable is not a good selection if the machine is under heavy and/or variable load that causes the clock to drift by significant amounts on an irregular basis.
Since Domain Time may select a large window size if the clock on the machine has been well-behaved, anything that causes sudden clock drift during the Window period between checks can cause the clock to drift outside the specified threshold before the next correction.
If this describes your machine, you should use the Fixed schedule instead.
Fixed - check once every
Days
Hours
Mins
Secs
If this option is selected, Domain Time will synchronize regularly on the schedule you specify.
This method is a good choice when you want to discipline the clock to stay within very tight synchronization tolerances. It's also the
best choice for machines with highly variable load, poor timekeeping hardware, or any other issue that causes significant clock drift.
You should check the time often enough to keep your clock within your desired accuracy.
Since having highly-accurate time at all times is usually more critical on Servers, you will likely want to check often using a fixed schedule on Servers.
CAUTION: Take care with this setting. Many time servers have Denial-of-Service (DOS) protection to prevent abuse.
Issuing too many time requests in a row to one server over a short period of time can cause your machine to be locked out or even be permanently blacklisted.
This problem can be exacerbated if you have opted to collect multiple samples per time source. See About Time Samples.
See the "Finding the Sweet Spot" sidebar on the right for more info on picking the correct sync rate.
You may set a different rate for Domain Time to use if it cannot contact any time source.
If Domain Time cannot obtain the time, it should try again every:
Days
Hours
Mins
Secs
sets how often Domain Time will retry its time sources if it is unable to successfully obtain the time. You will probably want to
check more often than during normal operation (unless you're already using a frequent synchronization schedule) to reacquire the correct time quickly when your time source(s) become available.
The same caution about synchronizing too often against your time sources (discussed above) applies.
Timings
Group Policy applied indicator in the lower-left corner of the applet,
there are settings on this page that are being overridden by an Active Directory Group Policy. Settings controlled by policy may be greyed-out or you may be otherwise prevented from making a change here.
See the 
Proceed to the Correction Limits page
Back to the IEEE-1588 (PTP) page