in message
? Wasn't the goal to not have to do that, instead improve
accuracy of the system clock?
So say he has his own atomic clock so he is measuring time as accurately
as we have technology to measure it. Then he goes connecting once an
hour onto the Internet to resync his clock. If he uses the same NTP
server, say, at his local university, one poll takes a route from his
ISP to a hub to which his university connects but there is a ton of
traffic at the time. Another poll has him ISP routing his traffic to a
backbone hub a couple states away and then back but at that time there
wasn't much traffic. Every time he syncs, the offset is going to be
different. He has the most accurate clock but the *poll* says he is off
3ms one time, a minute in another poll, minus 12 seconds on the next
poll, and so on. Is he really going to change the setting of his most
accurate atomic clock? Yep, because he is accepting the value he gets
over a public network shared by many to get at a secondary or tertiary
NTP server. Doesn't matter how accurate is the computer's clock. On
every NTP poll, the offset will vary. The OP is polling once a week.
Even once an hour isn't much of a sampling size. If you expect two, or
more, servers to remain in close sync with each other, you better be
bouncing the ball at less than 1-minute intervals.
The accuracy of low-end consumer-grade computers exceeds the clock
offsets encountered for polls over the Internet. You can't get much of
a running average using clock offsets collected at 1-week intervals. As
mentioned in RFC 1305, "It should be recognized that clock
synchronization requires by its nature long periods and multiple
comparisons in order to maintain accurate timekeeping." That is,
variance is greatest at the start of the sampling and is expected to
level out. Unfortunately you have no control over the consumption of
the Internet at each poll. The next sentence says, "While only a few
measurements are usually adequate to reliably determine local time to
within a second or so, periods of many hours and dozens of measurements
are required to resolve oscillator skew and maintain local time to the
order of a millisecond." That works if the offsets are small or
identically sized. Does the OP really need more than a second or two -
per week - to consider his clock as accurate? But then it will be a
"few measurements" (i.e., a few weeks). I prefer polls once an hour and
having reasonable accuracy in a couple hours. At week-long poll
intervals, a "flyer" could skew the bias significantly for a couple more
weeks.
As mentioned at
http://www.seis.com.au/TechNotes/TN200407A_NTP.html,
"One issue we have not yet discussed, is how often a new estimate of
clock offset should be made to ensure that the clock stays "on time".
This is another area where NTP version 4 is considerably improved on
earlier versions. In NTP parlance, this is called the poll interval, and
the algorithms are designed for poll intervals ranging from 16 seconds
to greater than one day. The poll interval is determined dynamically
based on the observed clock offset measurements. Typically, if the
temperature of the oscillator is constant, the poll interval will
increase as better and better estimates are obtained of the oscillator
frequency. When the temperature changes, the oscillator frequency will
change and the poll interval will reduce to try and track these
changes." We haven't a clue if the OP leaves his computer on all the
time or if he powers it down just because he doesn't happen to use the
computer for awhile and how long are those intervals of power-down
versus power-up. The timing circuits in home computers are not encased
within a constant-temperature oven. So shorter poll intervals help
reduce the time to resync. 1-week poll intervals is like targeting in
your rifle at 1-week intervals between shots: it will take a lot longer
to zero in your scope. I have cable access to Internet and poll at
1-hour intervals. If you have dial-up access, you may not be on long
enough to get more than one, and maybe not even one, poll in your
connected session, so you should have a much shorter poll interval, like
15-minutes (provided you are regularly on for longer than that).
Unless you configure the time service your your 3rd party software as to
which NTP server to use, the default is time.windows.com. Well, that's
pretty useless since it is likely that you will go for long stretches
where you can't connect to that host, if at all. Go find a good NTP
server from one of the public lists to which you can actually connect,
or use software that checks amongst a large list of public NTP servers
to determine which works best at the time for your host time synching.
According to
http://www.microsoft.com/WINDOWS2000/techinfo/howitworks/security/wintimeserv.asp,
the Windows Time service was not designed to be a time solution on which
applications could rely. It's good enough for Kerebos authentication
that requires "loosely synchronized" across the network but not more -
unless you are targeting humans rather than computers as those that need
accurate time. Humans don't care if a file got modified a second
earlier or later. Have a read at
http://www.greyware.com/software/domaintime/product/w32time.asp and read
the paragraph containing "Windows Time service is just not sufficient
for a large percentage of real-world enterprise use." Don't expect W32T
to be more than 2 seconds accurate. However, as I recall, time
syncrhonization only occurs on workstations on login, so if you stayed
logged in for long periods then you don't get the needed sampling of
clock offsets to recalculate your time to make it accurate. Well,
that's how I thought it worked until I read
http://support.microsoft.com/default.aspx?scid=kb;EN-US;224799.
Basically the intervals are so long that it just looked like the only
time sync that I got was on login. 8 hours? Geez! No wonder 3rd party
or registry hacks are used to reduce this to 1-minute polls for time
sensitive processes or the programs running their components on
different hosts use its own heartbeat to keep in sync. One of the first
services I disable after installing Windows is the time service, and
then I use something better - but I definitely don't poll at 1-week
intervals! An hour is an eon to a computer but good enough for me
personally (unless I see more drift and have to lower the interval).
Not many users bother defining an event in Scheduled Tasks to run "w32tm
/resync" at, say, 1-hour intervals. What, you've never noticed that the
time on 2 workstations is significantly out of sync with each other
although they are both on the same domain using its PDC as the time
server? Software, like anti-virus, screen savers, power management, or
any program that can cause system delays can cause time loss of 30
seconds to a minute per week. That's why I prefer to run a utility to
poll at regular 1-hour intervals. Of course, if you logout at the end
of every workday then you don't care much, especially for a workstation.
I rarely logout so I need polls more often. 1 week is perhaps a short
time to a oblivious user. An hour is an eternity to a computer.
Depends also on whether the synchronization is for computers or humans.
Do you care that a file got modified at 10:41:22.823 or at 10:41:23.142?
Not likely, especially since you as the user don't normally get to see
at that level of granularity, but interconnected computers might.
