Corrections Correction Limits
Domain Time II Server
Version 5.2

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 Policy Applied 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.

 Minimum Correction 

Variances smaller than milliseconds will not cause a correction (unless overridden below)

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.

 

 Maximum Correction 

No maximum correction
 Variances larger than
  
HoursMinsSecs
will not cause a correction (unless overridden)

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.

 

 Limit Override 

Override the minimum and maximum:
        For sync signals, at startup, during training, and when triggered by Clock-Change monitor
        For sync signals, at startup, during training, but NOT when triggered by Clock-Change monitor
        Only on first correction after machine startup (within seconds of boot

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.

 

 Advanced Sample Validation 

Discard time samples that exceed milliseconds of historical average variance
Discard time samples whose latency exceeds milliseconds, regardless of history

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.

 


Copyright © 1995-2024 Greyware Automation Products, Inc.  All Rights Reserved
All Trademarks mentioned are the properties of their respective owners.
Greyware Automation Products, Inc.
308 Oriole Ct, Murphy, TX 75094
972-867-2794 (voice)

Close Printer-Friendly Version