Expected accuracy of time clock on Intel Core-2 with Vista??

[maruk2]

What is the expected accuracy for the time clock on a PC
with Intel Core-2 6300 at 1.86GHz, 32-bit Vista?

My Vista synchronizes with an Internet server on Sat at 9pm.
I checked on Sat after 9pm and the PC time clock was accurate
to every second. On Sunday evening it was 2 seconds fast,
today on Monday it is 4 seconds fast, i.e. it seems to gain
2 seconds per day.

Does it mean that the latest PC technology still cannot ensure
time clock accuracy at least -/+ 1 second per week?
Are there any expansion boards available to rectify the problem?

 

[John McGaw]

What is the expected accuracy for the time clock on a PC
with Intel Core-2 6300 at 1.86GHz, 32-bit Vista?

My Vista synchronizes with an Internet server on Sat at 9pm.
I checked on Sat after 9pm and the PC time clock was accurate
to every second. On Sunday evening it was 2 seconds fast,
today on Monday it is 4 seconds fast, i.e. it seems to gain
2 seconds per day.

Does it mean that the latest PC technology still cannot ensure
time clock accuracy at least -/+ 1 second per week?
Are there any expansion boards available to rectify the problem?

What it means is that your PC uses the cheapest possible crystal for its
time standard and that has almost nothing to do with "the latest PC
technology". It has almost everything to do with saving a penny. As for
expansion boards, why bother? If you have a reliable internet connection
you can synchronize your clock more frequently and achieve +/- 1 second
accuracy very easily. I synchronize my machines once per day using a
free program called atomic.exe but there are others out there which are
equally free and which serve the same purpose. You can even, with a bit
of registry diddling cause Windoze to update more frequently than their
pre-ordained weekly interval although for some reason MS seems to have a
difficult time with this relatively simple task.

There are numerous sites and pages covering the whole subject of time
synchronization and a search will turn them up readily. You can even, if
you feel daring enough set up your own time server synchronized directly
to the national standard and then synchronize other computers on a
network directly to that.

 

[maruk2]

What it means is that your PC uses the cheapest possible crystal for its
time standard and that has almost nothing to do with "the latest PC
technology". It has almost everything to do with saving a penny. As for
expansion boards, why bother? If you have a reliable internet connection
you can synchronize your clock more frequently and achieve +/- 1 second
accuracy very easily. I synchronize my machines once per day using a
free program called atomic.exe but there are others out there which are
equally free and which serve the same purpose. You can even, with a bit
of registry diddling cause Windoze to update more frequently than their
pre-ordained weekly interval although for some reason MS seems to have a
difficult time with this relatively simple task.

There are numerous sites and pages covering the whole subject of time
synchronization and a search will turn them up readily. You can even, if
you feel daring enough set up your own time server synchronized directly
to the national standard and then synchronize other computers on a
network directly to that.

The problem with frequent synchronizations is that it may lead to
timestamps
that are out of order. For example, if you have a server program
running in the
background 24/7 around the clock that collects real-time events and
saves a
timestamp of each event you may end up with events that are out of
order
when a sync sets the clock back a few seconds. Syncing once per week
Sat/Sun night is fine but not more frequent than that.

Besides, Internet synchronization is rather primitive because the
protocol
is very primitive. You always have to check visually the time after
so called
synching. I would rather do it only once per week.

 

[Sjouke Burry]

What is the expected accuracy for the time clock on a PC
with Intel Core-2 6300 at 1.86GHz, 32-bit Vista?

My Vista synchronizes with an Internet server on Sat at 9pm.
I checked on Sat after 9pm and the PC time clock was accurate
to every second. On Sunday evening it was 2 seconds fast,
today on Monday it is 4 seconds fast, i.e. it seems to gain
2 seconds per day.

Does it mean that the latest PC technology still cannot ensure
time clock accuracy at least -/+ 1 second per week?
Are there any expansion boards available to rectify the problem?

I use "Atomic clock sync" from
www.worldtimeserver.com.
It keeps the clock synced to the second.

 

[maruk2]

I use "Atomic clock sync" fromwww.worldtimeserver.com.
It keeps the clock synced to the second.

All syncing programs have to use the same protocol syncing
to the "second", i.e. it may be one second or 5 seconds.

Since the protocol is primitive all syncing programs
are primitive to the "second", i.e. it may be one second or
5 seconds.

The issue here is not syncing but the accuracy of the
PC time clock or any way to use an expansion
board with highly accurate clock so that the syncing
is reduced to a minimum.

 

[John McGaw]

The problem with frequent synchronizations is that it may lead to
timestamps
that are out of order. For example, if you have a server program
running in the
background 24/7 around the clock that collects real-time events and
saves a
timestamp of each event you may end up with events that are out of
order
when a sync sets the clock back a few seconds. Syncing once per week
Sat/Sun night is fine but not more frequent than that.

Besides, Internet synchronization is rather primitive because the
protocol
is very primitive. You always have to check visually the time after
so called
synching. I would rather do it only once per week.

You seem quite certain that synchronization is "rather primitive". Sure,
good old NTP is getting a bit long in the tooth but there are probably a
half-dozen other protocols out there and some are certainly good for
better than 1 second accuracy. NTP4 comes immediately to mind as being
good for 1ms accuracy. And there are other solutions using a combination
of synchronization, drift analysis, and corrections applied many times
per second which can keep clocks across a facility accurate to better
than 100ms even if external reference time is lost for some period.
Simple and relatively inexpensive (inexpensive if one really has need of
such accuracy, that is) GPS synchronization equipment and software can
readily give continuous +/- 50ms accuracy directly traceable to NIST.
And it doesn't even need an add-in card of any sort.

 

[kony]

On May 14, 12:42 pm, John McGaw <[email protected]> wrote:

The problem with frequent synchronizations is that it may lead to
timestamps
that are out of order. For example, if you have a server program
running in the
background 24/7 around the clock that collects real-time events and
saves a
timestamp of each event you may end up with events that are out of
order
when a sync sets the clock back a few seconds. Syncing once per week
Sat/Sun night is fine but not more frequent than that.

Then why not just sync once per week?
It seems like you're trying to fix something that isn't a
problem.

 

[kony]

The issue here is not syncing but the accuracy of the
PC time clock or any way to use an expansion
board with highly accurate clock so that the syncing
is reduced to a minimum.

Then buy some high grade crystal somewhere and replace the
one on the board.

 

[Vanguard]

What is the expected accuracy for the time clock on a PC
with Intel Core-2 6300 at 1.86GHz, 32-bit Vista?

My Vista synchronizes with an Internet server on Sat at 9pm.
I checked on Sat after 9pm and the PC time clock was accurate
to every second. On Sunday evening it was 2 seconds fast,
today on Monday it is 4 seconds fast, i.e. it seems to gain
2 seconds per day.

Does it mean that the latest PC technology still cannot ensure
time clock accuracy at least -/+ 1 second per week?
Are there any expansion boards available to rectify the problem?

No, it means the delay between you and the timeserver over the network
is variable because obviously you don't have a dedicated line over which
only your traffic is allowed. I sync my clock once per hour and I use
whatever is the fastest responding timeserver from a long list of them.
That means that I do NOT use the time service in Windows since you can
only specify a couple timeservers there. The geographically closest
timeserver is not necessarily the fastest over the Internet (you could
have one in town a mile away but your connection goes off on the ISP's
backbone to a major hub, like Chicago, and then bounces back). You have
no control over the path taken to a timeserver or any server. You have
no control over the saturations of those interconnected networks.

I use Socketwatch but there are probably others that can also poll
around trying to find whatever is the then currently fastest *accessed*
timeserver from your host point. My local university provides 2 NTP
servers. Yet they are not always the fastest (least delay) to get the
current time. I might end up using one at Purdue or at a university in
Germany. All depends which is fastest to respond at the time of the
poll.

You could repeatedly resync using the same server over a network and
notice that each one varies in its offset from before. You are
synchronizing over a non-dedicated network. If you want absolute
accuracy that is repeatable then you need to not sync across a TCP
network and instead somehow hook into the radio transmission. Control
towers for airports do NOT time sync over the Internet, nor anyone else
that needs repeatable results on every time check.

So just what operation are you performing in real-time where a
difference of, say, 2 seconds between various hosts in your intranet
will cause severe distress in results?

 

[Vanguard]

in message

Then buy some high grade crystal somewhere and replace the
one on the board.

A better crystal and tighter timing circuit probably won't help much.
The OP is synchronizing to an NTP server over the Internet, not using
the radio broadcast.

 

[kony]

in message



A better crystal and tighter timing circuit probably won't help much.
The OP is synchronizing to an NTP server over the Internet, not using
the radio broadcast.

? Wasn't the goal to not have to do that, instead improve
accuracy of the system clock?

 

[kony]

No, it means the delay between you and the timeserver over the network
is variable because obviously you don't have a dedicated line over which
only your traffic is allowed.

I think you are missing the point, which was that the time
was sync'd reasonably from server to client, but then the
more time that elapses, the more the error from the client
m'board clock causes addt'l deviation in system time from
real time.

The other alternative would be a more frequent sync of all
systems that need sync'd to each other.

 

[Paul]

All syncing programs have to use the same protocol syncing
to the "second", i.e. it may be one second or 5 seconds.

Since the protocol is primitive all syncing programs
are primitive to the "second", i.e. it may be one second or
5 seconds.

The issue here is not syncing but the accuracy of the
PC time clock or any way to use an expansion
board with highly accurate clock so that the syncing
is reduced to a minimum.

When the computer is sleeping, time is maintained by the
RTC (real time clock) in the Southbridge. There is a 32.768 KHz
quartz crystal next to the Southbridge, and that crystal works
with something that is very similar to a digital watch. The
quartz crystal itself, might be something you'd find in a
digital watch. Timekeeping when a computer sleeps, would be
no better than your digital watch.

When the computer is running, it is my understanding that
clock tick interrupts are counted in software, and the OS
maintains timekeeping. The RTC is read when you wake the
computer, and software then counts clock tick interrupts
from then on. Presumably the clock generator chip (the one
that feeds 266MHz to your Core2 Duo processor) is the
source of timing at that point.

This article is about a virtual machine, but happens to
include a short section about the main OS.

http://support.microsoft.com/kb/918461/en-us

"An operating system generally tracks time by using the
periodic time interrupts that are generated by a specific
hardware device. Generally, an operating system obtains the
time from a battery-backed Complimentary Metal Oxide
Semi-conductor (CMOS) clock during the operating system's
startup procedure. The operating system then configures a
timer device to generate periodic interrupts. The operating
system keeps track of time by counting these interrupts."

You complain of seeing a 2 second error after one day,
and a 4 second error after two days. That pattern suggests
a steady "drift rate", and that is a good thing. A non-steady
drift rate is harder to correct. If you use NTP to maintain
synchronization, it is supposed to actually compensate for
the "drift rate". In other words, if the software tracks
that a drift is present, it computes the drift rate and uses it for
correcting the system time, and can give good results.
So part of the job of NTC, is figuring out what the drift
rate is, after several syncs.

When NTP synchronizes, there are claims that the synchronization
can be better than 1 second. (It will be some function of the latency
of packet delivery from NTP server to client.) Since the operating
system time keeping function has a resolution better than 1 second,
the resolution of the OS clock is not a problem. Putting the
computer to sleep and waking it again might cause more of
an issue, as I think the resolution of the RTC (backup clock)
might be 1 second.

If you don't like to connect over the Internet to maintain
the time, GPS is another option. The third link is to a GPS
product with a USB interface, and costs $29. As long as the
GPS receiver "puck" is positioned where it can pick up a
signal from the GPS satellites, you can get your timekeeping
that way. That is much cheaper than a real timekeeping board.
Between GPS corrections, the time will still be maintained
by the computer's clock tick interrupts, in the normal way.
Using GPS avoids the need to query an Internet source.

http://www.free-news-release.com/Freeware-GPS-Clock-Software-Detail_26964.html
http://en.wikipedia.org/wiki/NMEA
http://www.geeks.com/details.asp?InvtId=UT-41&cpc=RECOM

This is an example of a card that plugs into a PCI slot.
The card has a 64 bit connector, but is keyed for 3.3V or 5V
operation, and should work in a desktop as well. Page 15
here shows a picture of the product (RCIM II). It has a
GPS module, plus it has an option for an OCXO (oven
controlled oscillator). The claim is, the oven controlled
oscillator maintains 0.01ppm drift, between GPS
updates. That would give a better result than the $29 solution,
but so far I haven't been able to find a price for this thing.
Judging by the look of the thing, a price of >$1000 is likely.
Basically, this card is replacing your clock generator drift
rate, with the OCXO oscillator.

http://www.ccur.com/isdmanuals/2Red...Module_(RCIM)_PCI_Form_Factor_Users_Guide.pdf

You can also buy "atomic clock" quality devices, for even better
local results. But to be traceable to stratum 0, you still need
some outside influence, like GPS or an Internet connection. Even
an atomic clock has correction factors and drift with respect
to the constellation of external atomic clocks.

Due to the interface between the OS, and any timekeeping device
(PCI bus for example), I doubt spending more than the $29 above
is worthwhile. With respect to the GPS, remember that the GPS
device sends a text string to the computer, in this case over USB,
so there is still some latency and latency variation, between
when the GPS receives a message, and when the OS gets it.

Have fun,
Paul

 

[Vanguard]

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.

 

[kony]

in message



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.

Why would you resync if it's accurate? Seems like a
solution without a problem at that point. Just sync the
systems that need sync'd and forget about the time server.

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.

The answer is simple, don't use a busy time server. If the
lan is really that busy, don't sync during peak times.
Otherwise, it should not take 1 second more either time, the
error is less than the resolution at which the clock
displays time.

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.

I disagree entirely, it is unlikely the time will be off by
much at all due to the network congestion and if it is, this
is easily measurable to pinpoint such a problem.

Doesn't matter how accurate is the computer's clock.

Yes it does, that is the whole problem. With an accurate
clock there is no longer a need to sync to a time server,
but suppose you insist on it- ok then, sync to a local one
without the congestion along the path.

On
every NTP poll, the offset will vary.

Not enough to matter in most cases. OP didn't ask for small
fractions of a second accuracy.

 

[GT]

My Vista synchronizes with an Internet server on Sat at 9pm.

I checked on Sat after 9pm and the PC time clock was accurate
to every second. On Sunday evening it was 2 seconds fast,
today on Monday it is 4 seconds fast, i.e. it seems to gain
2 seconds per day.

Does it mean that the latest PC technology still cannot ensure
time clock accuracy at least -/+ 1 second per week?
Are there any expansion boards available to rectify the problem?

[snip]
You can even, with a bit
of registry diddling cause Windoze to update more frequently than their
pre-ordained weekly interval

[snip]
The problem with frequent synchronizations is that it may lead to
timestamps
that are out of order. For example, if you have a server program
running in the
background 24/7 around the clock that collects real-time events and
saves a
timestamp of each event you may end up with events that are out of
order
when a sync sets the clock back a few seconds. Syncing once per week
Sat/Sun night is fine but not more frequent than that.

You haven't told us what exactly you are measuring, but if changing the
clock regularly makes a mess of your data, then I would suggest leaving your
clock alone. You could manually put the clock back by 1 minute every month
as that sounds about the extent of the innacuracy (2 seconds per day). This
way, you would know exactly when the clock change is hapenning.