Clock accuracy

  • Thread starter Thread starter KenK
  • Start date Start date
KenK said:
Is the source of the clock time in the task bar in XP Home accurate? Like
WWV maybe?

TIA
Click to expand...

Well, first you check your "Date and Time" properties,
and see whether you're pointed at an actual, working,
time source. Mine is set to time.windows.com right now.

My modem/router, points to 2.pool.ntp.org , which is a
load balanced pool of hundreds of NTP time servers. By pooling
resources, no one server owner is plagued with time stamping
all the computers on Earth. The bandwidth used, is actually
an issue for those owners. The more servers in the pool, the
less each server owner is paying as a "donation".

*******

You can turn on logging, but the log file is "filled with crap".
I've extracted a few lines, that gives me some idea it is running.

"How to turn on debug logging in the Windows Time Service"

http://support.microsoft.com/kb/816043

C:\WINDOWS\Temp\w32time.log

150608 21:35:00.7031250s - Polling peer time.windows.com
150608 21:35:00.7031250s - Sending packet to time.windows.com
....
150608 21:35:00.7812500s - LocalClockOffset: 0:00.486668500s

So far, nothing stands out in that file, to suggest Windows
uses a "linear dribble" correction model.

A third-party NTP client, may actually have better internal
modeling than the Windows one. But that's only for purists,
and for people lucky enough to not have any hardware issues.
(Hardware issues can swamp even the best software...)

*******

Your computer has more than one clock.

When the computer is off, the RTC in the Southbridge keeps time.
The RTC uses a 32768Hz watch crystal, and the crystal can be
located near the Southbridge. But the communications path to
that hardware, is extremely poor, and so it is not practical
to look up the time from that time piece on a regular basis
(like, once a second).

When the OS boots, RTC time is copied to a software clock service.
The software clock counts "clock tick interrupts". The clock tick
interrupts, in turn, are traceable to the clockgen chip and the
crystal located next to it. So the "drift" of your system, is
determined by more than one crystal. While the clockgen also
contributes a reference clock to the CPU itself (for the CPU PLL),
we don't even want to discuss how that works (SpeedStep, ugh!).
Counting clock tick interrupts, avoids worrying about whether
the CPU is running 2GHz or 3GHz right now. There are actually
other time pieces inside the computer, beside counting clock ticks,
and they all have to be synchronized, somehow.

A good NTP implementation, uses linear drift compensation. Meaning,
if the RTC or Clockgen loses 50ppm per day, the software clock
can "dribble out" small corrections to the clock, on a more frequent
basis. But linear modeling doesn't even come close to real-world
behavior. (Drift could be temperature sensitive, room temp changes...)

If clock tick interrupts ever get lost, due to some high priority
activity taking longer than a clock tick, then the clock will
randomly drift in one direction. NTP cannot really compensate for
that, very readily. You can never turn up the NTP correction rate
high enough, to take care of every problem type.

Owners of motherboards with Nforce2 chipset, they had a problem
with time that was so bad, that no NTP method could keep up with
the random drift. It was short term random, meaning the on-screen
(analog-looking) clock, couldn't even time 60 second periods without
huge errors. There was some kind of bug in the interrupt logic
of the motherboard, and one trigger condition, was a non-canonical
adjustment of hardware clock (like, setting your DDR333 DIMM to
run at DDR320, that sort of thing). No NTP algorithm, can
successfully correct for short term random +/- type events.
And that clock could be off by seconds per minute, gaining
one minute, losing the next. Returning hardware timing clocks
to nominal (run DDR333 DIMM at DDR333 rate), would cure the
problem for some, but I think there were still a few victims,
where nothing worked for them. I had one of those motherboards,
but didn't have a bit of trouble with mine. Go figure.

*******

The best-written articles on time keeping, come from the software
developers who do VM software. Check the VMWare, VirtualBox sites
and the like, as they explain how PIT works, whether they use HPET,
that sort of thing. And they'll give some ideas, how OSes keep time.
The copying of the RTC to the software time service, is just
a small part of it.

Paul
 
philo  said:
If you have it set to synchronize with a time server, then yes.

Otherwise the time is simply kept by your BIOS clock and will drift
slightly.
Click to expand...

Only until the OS loads. Then the BIOS clock (real-time chip) is no
longer used and the OS system clock is used -- which means on a
heavily loaded host the OS clock does and will get off hence why
Windows comes with a time sync service to get time for a NTP server.

The RTC drifts very little until the CMOS battery gets low (which
means the RTC doesn't get enough or no power when the host is powered
down as it does get power when the computer is up). As I recall from
the last time I checked, the RTC chip drifts about 1 minute per year.
However, the OS clock can drift a lot on a heavily loaded (very busy)
computer. If you're constantly editing or converting video files then
the OS clock will drift more.

The hardware clock (RTC) is very good at keeping time. The OS clock
is not hence the need to re-sync it periodically.
http://www.microsoft.com/resources/.../en-us/windows_date_it_overview.mspx?mfr=true
Click to expand...

Microsoft's own NTP servers are heavily overloaded. They didn't ramp
up their capacity as more consumers purchased their Windows products.
The result is that your host may not get synchronized to their NTP
server for a long time, like weeks. During that time a heavily used
host get off so far in time that SSL connects won't work (because the
tokens passed during the handshaking are timestamped and old tokens
are considered invalid in an attempt to prevent interference and
enhance security).

If the system clock lets you pick a different NTP server than
Microsoft's then do that. Microsoft only included one other NTP
server but that gov't one is also highly targeted. You can add to the
list of available NTP servers from which you can select by going into
the registry and adding them to:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\DateTime\Servers

I have Microsoft's NTP server, a few from the gov't, and my local
university's NTP server (which is the one I pick). Once you add more
NTP servers to which you can more reliably connect so you actually do
get a time sync (you can check the Event Logs to see how often the
sync fails), you go into the OS clock setting to select that server.

Remember that the Windows Time Service will only sync your OS clock
about once a week no matter which NTP server you pick. If you want
more frequent updates than that, like you are operating a file server
where timestamps are critical, then you need to employ 3rd party NTP
software. 3rd party time sync utilities often have a long list of
available NTP servers and some of them will measure the time delay
from each to give you the one with the least lag which may not always
be the same NTP server nor even the most physically close NTP server
(because nodes in the route can vary in their delay in routing
traffic).

There are lots of free "atomic clock" time sync utilities out there.
Some are very basic and do nothing more than the Windows Time Service
other than sometimes provide you with a pre-compiled list of NTP
servers so you don't have to go find them with an online search. The
simple ones let you pick an NTP server but never change to another
one. Some are better in that they test the NTP servers to determine
which is the best one for you to use at the time for the sync and will
move onto another one if the sync fails (no connect, server won't
respond, host not reachable, timeouts). I use SocketWatch (payware)
but it's pretty old. NTP hasn't changed but the pre-compiled list
that comes with Socketwatch is out of date and you have to manually
edit its text database file after figuring out its syntax. There are
others that are probably as good but I haven't bothered to investigate
them.

After getting away from the 2 NTP servers pre-defined in Windows
(Microsoft's and the common NIST one), I don't run into failed sync
attempts when using my university's NTP server. Once per week
(providing you really do get one every week) is enough for my host.
However, if I was using it far more heavily and constantly doing so
then I'd go back to use 3rd party NTP software. An offset of a minute
per week (usually it's under a few seconds) for how I do load my OS is
small enough for me not to worry.

While the Windows Time Service adds entries into the Event Log
(system) each time it attempts a sync event, it won't tell how off was
the offset that had to be compensated. 3rd party NTP software might
but you'll have to check their UI to see if they report how much was
the change they made to the OS clock.
 
Besides the registry key mentioned for where you can add (or remove)
NTP servers (so you could have one, or more, from which to select that
are more reliable for connects), there are other registry settings to
configure the Windows Time Service (W32time) if you intend to stick
with what came with Windows instead of using a 3rd party NTP sync
tool. See:

http://technet.microsoft.com/en-us/library/cc773263(v=ws.10).aspx

Lots of settings there and many you (and I) really can't decipher as
to what they do. Of interest is the description for:

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient
Data item: SpecialPollInterval

This is where you can specify how many seconds between poll intervals.
The defaults are: 604800 seconds (1 week) for most Windows hosts, 3600
seconds (1 hour) for Windows hosts logged into a domain server. You
could reduce this to 86400 seconds (1 day) to *try* to get Windows to
sync once per day. I said "try" because with this value my Windows
host often syncs every 3 days, not every day. So it seems this is
more of an eligibility setting for how long after the prior update
when might be the next one rather than the actual next scheduled
update interval.

I had this changed to 86400 seconds (1 day) for quite awhile now. The
3 days that I typically get for the actual poll interval is usually
often enough to catch just a few seconds of OS clock drift on my host
for how I currently use it. If my host were far more heavily loaded
then I'd probably reduce this eligibility polling interval to a lower
value. Note that if you poll too often the NTP server may consider
this abuse and they decide to block your IP address for awhile.
 
Zo said:
KenK expressed precisely :
Click to expand...

No, it's based on the clock on your motherboard. There are plenty of
utilities that _will_ synchronise you to one of a reasonably large list
of "time servers" around the world (I don't know if including WWV), such
as that below, but remember that none of these give you accuracy better
than the cross-internet propagation time: they basically send a "what
time is it" query to whichever time server you choose (or is hard-coded
into them), and amend your clock based on the reply. You don't know how
long the query took to work its way over the internet to the server, nor
how long it took for the reply to get back to you, so it's not _that_
accurate. Some of the utilities won't amend your clock by more than a
certain amount (sometimes user-settable) to avoid problems due to a
really bad exchange of request/reply.

If all you want to do is to guard against your clock having been
accidentally set wrongly (or if it has a bad drift - though that's
usually a sign the CMOS cell needs replacing), they're fine.
 
Only until the OS loads. Then the BIOS clock (real-time chip) is no
longer used and the OS system clock is used -- which means on a
heavily loaded host the OS clock does and will get off hence why
Windows comes with a time sync service to get time for a NTP server.

The RTC drifts very little until the CMOS battery gets low (which
means the RTC doesn't get enough or no power when the host is powered
down as it does get power when the computer is up). As I recall from
the last time I checked, the RTC chip drifts about 1 minute per year.
However, the OS clock can drift a lot on a heavily loaded (very busy)
computer. If you're constantly editing or converting video files then
the OS clock will drift more.

The hardware clock (RTC) is very good at keeping time. The OS clock
is not hence the need to re-sync it periodically.
Click to expand...

Whoa! Where on Earth did you hear that? Manufactures don't spend much
money on computer clocks and I hear they spend only a buck or two on
this in hardware. And IMHO they keep time as well as your average $10
watch. And during one month, I would expect the worst to lose a minute
or more per month.

I normally use an old program called Dimension 4 v5 which stores all of
the information about time and checks it with a server that uses atomic
time (you can still download it). And if I haven't used that computer in
a year or two, 10 minutes or more being off isn't uncommon.
 
Back
Top