J
John Wunderlich
Flightless Bird
VanguardLH <V@nguard.LH> wrote in
news:hsvjhr$p6n$1@news.albasani.net:
> 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
is:
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:
MaxAllowedPhaseOffset
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
news:hsvjhr$p6n$1@news.albasani.net:
> 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
is:
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:
MaxAllowedPhaseOffset
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