Settings on this page control what corrections to the system clock are acceptable.
Note:
If Domain Time Server on this machine is set as a Slave server, some of these items will be unavailable since Slaves inherit their timing settings from the Master server.
See Domain Roles for more information on Master, Slave, and Independent Server roles.
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.
CAUTION: The default settings on this page are usually correct for most applications. Only make changes if you are sure you need them and you fully understand the effects of the change.
Incorrect settings may adversely affect your clock accuracy or even prevent clock corrections entirely.
IMPORTANT: Settings on this page do not apply (or have minimal effect) if you are synchronizing using IEEE 1588 (PTP).
AS OF v5.2.b.20170922, the Minimum Correction setting is obsolete and has been removed from the applet
The documentation in this section is for reference purposes on older versions only. If you still need to change
this value, please see the Server Settings registry key.
This setting controls the minimum amount the clock must be off from the time source(s) before it is corrected during a time check.
If you are using a variable synchronization schedule (see the Timings page), you will probably not want to incur
the extra overhead of correcting the clock if the variance found during a time check is smaller than your selected synchronization target.
For example, if you have instructed Domain Time to aim for a target variance of 25 ms, you do not need to make a clock correction if the detected
clock variance during a time check is only 10 ms. Making a correction in this case would only result in extra processing overhead and clock slewing
without much affecting your overall accuracy. So, in general, if you are using variable targeting, you will want to set this value to be the same
value or less than your target variance.
However, if you are using a fixed sync schedule, you will want to be sure the clock is corrected to the maximum accuracy on every synchronization. In that case, this value should be set to 1 millisecond.
This also enables Domain Time's high-precision sub-millisecond alignment function, so that any variances detected that are less than 1 millisecond will have the clock aligned to match, giving you
an added order of magnitude of possible accuracy.
This setting can be overridden under certain circumstances so that the clock can be forced to be corrected. See the Limit Override section below for details.
This setting controls the maximum variance that should be corrected during a time check.
This setting provides a vital sanity check to prevent wild time changes in the event your time source(s) provide a rogue time value (such as sometimes occurs when bounds limits are exceeded or error conditions occur in time clocks or the network).
For example, assume you have restricted this value to not allow corrections for variances larger than 2 hours. If a time source suddenly goes crazy and provides a time/date from 1980, the rogue time
correction will be rejected.
The default setting for this value is fairly generous, so you may want to restrict this more in your environment. Do be careful to not restrict this value too tightly.
If you have clocks on the network that drift significantly under normal circumstances without restarting (such some laptops do when resuming from sleep modes), setting this value too low
may prevent them from ever correcting the clock until they are rebooted.
This setting can (and usually must) be overridden under certain circumstances so that the clock can be forced to be corrected. See the Minimum/Maximum Limit Override section below for details.
This setting also interacts directly with the clock slewing settings (which control whether corrections are made by slewing or stepping). See the Clock Control page for details.
Use these settings to control when Domain Time will override the correction limits to force a time correction.
The default selection is usually the best option since there are a number of situations where you typically want the time to always be corrected regardless of how far off
it may be from the correct time such as:
when the time service is started
when triggered to force a correction
when the clock is being trained (see the Correction Reduction section of the Clock Control page)
when Doman Time's Clock-Change Monitor detects that a user or application has unexpectedly attempted to change the time
However, your particular needs may require the ability to restrict corrections even further. If so, you will want to select one of the other listed options. Do be sure
you fully understand the effects of this selection if you change it from the default.
This setting interacts directly with the clock slewing settings (which control whether corrections are made by slewing or stepping). You may use the override settings in combination with slewing/stepping limits
to ensure that corrections are made only under the precise conditions you desire. See the Clock Control page for more details.
These settings set boundaries on the maximum variance and/or latency permitted in individual time samples.
Discard time samples that exceed milliseconds of historical average variance
Checking this box enables an additional check which may help protect against significantly delayed or skewed time samples. See About Time Samples on the Obtain the Time page for details on how time samples are used.
This setting is turned off by default to minimize overhead, since the default expectation is that your network and time sources will generally be well-behaved. However, if you experience
unusual spikes in the time from otherwise reliable sources, you may want to enable this setting to help screen out the errant samples that would otherwise skew your time calculations.
When enabled, Domain Time will keep a historical record of time samples from your selected time sources. It will then reject any time samples that exceed the historical average of the time source by the threshold value you select here.
For example, assume you have set this threshold to 500ms. The historical average variance of time server tick.mydomain.com to date has been +50ms but suddenly
a time sample is received with a variance of -475ms. This new sample varies from the historical variance by more than the 500ms threshold value you've set, so the
sample will be rejected.
CAUTION:
As with other settings on this page, you should only enable this function if you fully understand the ramifications. If you set this value incorrectly, you may end
up rejecting so many samples Domain Time will not be able to correctly identify the correct time, or may even be unable to set the clock entirely.
Use the Trace or Debug log detail of the Text Log to see if samples are being rejected and how the accepted samples are being analyzed.
Discard time samples whose latency exceeds milliseconds, regardless of history
This setting is similar to the function described above, except that it rejects individual samples based on a latency limit you specify. This feature was introduced in version 5.2.b.20110309.
CAUTION:
As with other settings on this page, you should only enable this function if you fully understand the ramifications. If you set this value incorrectly, you may end
up rejecting so many samples Domain Time will not be able to correctly identify the correct time, or may even be unable to set the clock entirely.
Use the Trace or Debug log detail of the Text Log to see if samples are being rejected and how the accepted samples are being analyzed.