Re: Expected accuracy of time clock on Intel Core-2 with Vista??
On Mon, 14 May 2007 19:45:33 -0500, "Vanguard"
<no@mail.invalid> wrote:
>"kony" wrote in message
>news:bbph43540khrgdualimri1999tinj1cjd2@4ax.com.. .
>> maruk2 wrote:
>>
>>>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.
>
>
>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?
Re: Expected accuracy of time clock on Intel Core-2 with Vista??
On Mon, 14 May 2007 19:43:43 -0500, "Vanguard"
<no@mail.invalid> wrote:
><maruk2@hotmail.com> wrote in message
>news:1179157770.640610.156950@o5g2000hsb.googlegr oups.com...
>> 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 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.
Re: Expected accuracy of time clock on Intel Core-2 with Vista??
maruk2@hotmail.com wrote:
> On May 14, 2:17 pm, Sjouke Burry <burrynulnulf...@ppllaanneett.nnlll>
> wrote:
>
>> 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.
>
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.
"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.
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.
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.
Re: Expected accuracy of time clock on Intel Core-2 with Vista??
"kony" wrote in message
news:e12i43tt2nnllgb2jemtv9v8frqcajel1j@4ax.com...
> "Vanguard" wrote:
>
>>"kony" wrote ...
>>> maruk2 wrote:
>>>
>>>>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.
>>
>>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?
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...intimeserv.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/dom...ct/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...b;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.
Re: Expected accuracy of time clock on Intel Core-2 with Vista??
On Tue, 15 May 2007 22:22:02 -0500, "Vanguard"
<no@mail.invalid> wrote:
>"kony" wrote in message
>news:e12i43tt2nnllgb2jemtv9v8frqcajel1j@4ax.com.. .
>> "Vanguard" wrote:
>>
>>>"kony" wrote ...
>>>> maruk2 wrote:
>>>>
>>>>>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.
>>>
>>>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?
>
>
>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.
Re: Expected accuracy of time clock on Intel Core-2 with 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?
>>
[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.
Re: Expected accuracy of time clock on Intel Core-2 with Vista?? 
Linear Mode
