1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Re: synchornize time - w32tm

Discussion in 'Windows XP' started by John Wunderlich, May 19, 2010.

  1. John Wunderlich

    John Wunderlich Flightless Bird

    VanguardLH <V@nguard.LH> wrote in

    > However, what I've seen and what the Internet Time tab in the Date
    > applet in Control Panel shows is that it could be several DAYS
    > before the next update. As I recall, it be a month before your OS
    > clock (not the RTC or BIOS clock) gets accurate to under a second.

    From further research, there are registry entries, namely:
    MinPollInterval, MaxPollInterval, and SpecialPollInterval
    that can be set to determine update rates. The Default for Min and Max
    1.1 minute < x < 17 minutes for Domain Controllers
    17 minutes < x < 9.1 hours for Domain Members and Standalones

    If the "Special Interval Flag" (never defined) is set, then the
    SpecialPollInterval kicks in and the defaults for that are:
    Domain Member Machines = 1 hour
    Other Machines = 7 days.

    > Also, a change of 2 hours, 1 hours, or even 10 minutes is far too
    > large for the situations that you are thinking of. For example,
    > SSL handshaking requires both ends to be close in their times
    > (I've never found just how close they must be). When the client
    > or server end is off by many minutes, the token in the handshaking
    > will have already expired so the other end refuses to establish
    > the SSL connection. That's why one of the fixes for failed SSL
    > connects is to check your time is accurate. There's no way SSL is
    > going to not expire a token that appears on the other end as 2
    > hours old.

    (I believe SSL time limit is around 5 minutes.)

    There are registry settings for this setting as well, namely:
    MaxNegPhaseCorrection, MaxPosPhaseCorrection
    If the time is off by more than these numbers, then it will not be
    corrected and an entry will appear in the system log.

    The defaults are:
    Domain Member Machines = Always set time
    Standalone Machines = Only set time if less than 15 hrs off.

    > You might as well as make the one-time big jump to recalibrate
    > your OS clock and live with any consequences from that one-time
    > event. Then keep your clock accurate thereafter. I can see that
    > gradual time convergence has value on, say, a file server where
    > you have a multitude of users that want the timestamp on a file to
    > have some value, but not on an end-user's host.
    > In the article you mention, it says "If the time difference
    > between the local clock and the selected accurate time sample
    > (also called the time skew) is too large to correct by adjusting
    > the local clock rate, the time service sets the local clock to the
    > correct time." Yet it does not define "too large". So we users
    > still don't know if convergence is used for, say, a differential
    > of a few seconds or few minutes or an hour or two or if anything
    > over, say, 5 minutes is considered "too large" resulting in an
    > immediate change rather than a gradual change. From
    > http://support.microsoft.com/kb/884776/en-us, it appears "too
    > large" default is all of 5 minutes.

    There is also a Registry setting for this, namely:
    The default setting for this parameter is:
    Domain Machines = 5 minutes (as you stated)
    Other Machines = 1 second.

    Putting this all together: By default, a non-Domain machine will
    immediately set its time if the amount of time it is off is between 1
    second and 15 hours. A Domain machine will immediately set its time if
    off by more than 5 minutes. If the time is off by less than these
    amounts, the system clock will be sped up or slowed down to slowly
    compensate. A non-domain (workstation) machine off by more than 15
    hours will not be set and an error logged is the System Log.

    All these numbers can be changed, of course.

    Interesting reading :)

    -- John

Share This Page