Time Synch Failing?

[(PeteCresswell)]

Last several weeks, my XP box has been coming up with incorrect times -
usually less than current but not on even hour boundaries (i.e. there's
no time zone issue).

Just found it set to 18:50 when the actual time was 19:38.

Opened up "Date and Time Properties", clicked "Update Now"... waited....
and waited... and sure enough, it reported an error while trying to
synch with time.nist.gov.

Flipped over to time.windows.com, and got a successful synch.

I *think* I recall an opposite situation when it started:
time.windows.com was selected but time was wrong. Switched over to
time.nist.gov and it synched.

Three Questions:

- OK, synchs are failing... but why is my PC's clock
getting so far behind?

- I've never had a time synch issue before... ever.
Has something changed vis-a-vis time synching?

- Is there an optimal address for time synching?

 

[Nil]

- OK, synchs are failing... but why is my PC's clock
getting so far behind?

I seem to recall that the sync will fail if the difference between the
local and remote time is too great. Not sure about that, though. Maybe
you'll find some more informative error messages in the Event Logs.
Maybe your motherboard's BIOS backup battery is dying?

- I've never had a time synch issue before... ever.
Has something changed vis-a-vis time synching?

Not that I know of, but I have noticed that sometimes the time servers
are occasionally unavailable for short whiles.

- Is there an optimal address for time synching?

I have my router set up to sync its time with us.pool.ntp.org every 4
hours, and I have all my local computers set to sync their time with
the router.

 

[Paul]

Last several weeks, my XP box has been coming up with incorrect times -
usually less than current but not on even hour boundaries (i.e. there's
no time zone issue).

Just found it set to 18:50 when the actual time was 19:38.

Opened up "Date and Time Properties", clicked "Update Now"... waited....
and waited... and sure enough, it reported an error while trying to
synch with time.nist.gov.

Flipped over to time.windows.com, and got a successful synch.

I *think* I recall an opposite situation when it started:
time.windows.com was selected but time was wrong. Switched over to
time.nist.gov and it synched.

Three Questions:

- OK, synchs are failing... but why is my PC's clock
getting so far behind?

- I've never had a time synch issue before... ever.
Has something changed vis-a-vis time synching?

- Is there an optimal address for time synching?

1) You can enable logging (w32timellog). Don't expect the answer to
be sitting in here in plain English though. Betting on this,
is a false hope. A third-party time sync tool and associated
log, may work out better for you.

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

2) Network time sources are occasionally mis-configured.
Even the "pool" type sources of time keeping, can have
rogue nodes (you're unlikely to be served by a rogue
node, twice in a row). I'm not betting on this being
the problem either.

3) When asleep, the 32KHz crystal on the motherboard, keeps
time like a digital clock. When the OS is running, a high priority
clock tick interrupt occurs many times a second, and is counted in
software. This is termed a "software clock". The interrupts generated,
are derived from a different crystal than the 32KHz one. This means
the drift on the two crystals, won't have exactly the same
characteristics. Again, this is likely noise. Especially if
you are using a good third-party time sync solution which
dribbles out time corrections regularly. The Windows one may
not work precisely that way.

4) Given (3), the issue becomes, what can interfere with a
"software clock" ? Windows doesn't probe the 32KHz BIOS
clock, but is relying on the software clock for timekeeping.

a) Missed clock tick interrupts. If interrupt level routines
have a longer runtime than the time between clock tick interrupts,
clock ticks get lost, and the software clock drifts in a
preferred direction. Normally, Windows runs at interrupt
level for as short a period as possible, scheduling the
rest of interrupt servicing as a DPC. The DPCLAT utility,
can be used to study DPC service latency, and determine by
side effect, whether something like BIOS SMM (System Management
Mode), is affecting the computer. Some Gigabyte motherboards
had slightly long SMM routines. And a BIOS update provided some
relief. Audio workstation owners typically look at DPCLAT (latency),
as audio recording can be affected by stuff like that. SMM is
used for things like some multi-phase VCore circuits, and
turning phases on and off on a whim.

(this leaves a service behind... if you're a neat freak,
you may want to remove it)

http://www.thesycon.de/deu/latency_check.shtml

Some SMM info.

http://en.wikipedia.org/wiki/System_Management_Mode

System Management Mode (BIOS code) is so powerful,
the OS doesn't know that it is happening. Seeing
spikes in DPCLAT, is a means to detect SMM activity
by the side effects on DPC service latency. If you see
a really long spike (many milliseconds), that might affect
a software clock and time keeping.

b) Hardware interrupt storms.

An Nforce2 chipset will suffer plus or minus drift,
large magnitude over a short time interval, if the
chipset is set to a non-canonical clock rate (over or
under clock). It is felt some chipset interrupt is
delivering bogus interrupts at a high rate, but nobody
analysed the problem that closely. No time sync solution
could fix this, because of the magnitude of the anomaly.

Plug-in cards can have interrupt storms. There was
one storage card, where 30% of chips had a bug like that.
Linux claims my RTL8169SC GbE NIC card is doing that too.
In this case, I would have expected the high priority
clock interrupt to not be affected. Windows has some
kind of protection against storms, but I don't know the
details. It won't give all CPU cycles to interrupts, and
limits them somehow.

So that's a bit of background on the hardware side.

Paul

 

[Hot_Text]

Last several weeks, my XP box has been coming up with incorrect times -
usually less than current but not on even hour boundaries (i.e. there's
no time zone issue).
Just found it set to 18:50 when the actual time was 19:38.
Opened up "Date and Time Properties", clicked "Update Now"... waited....
and waited... and sure enough, it reported an error while trying to
synch with time.nist.gov.
Flipped over to time.windows.com, and got a successful synch.
I *think* I recall an opposite situation when it started:
time.windows.com was selected but time was wrong. Switched over to
time.nist.gov and it synched.
Three Questions:
- OK, synchs are failing... but why is my PC's clock
getting so far behind?

it just one Hour for the daylight saving

- I've never had a time synch issue before... ever.
Has something changed vis-a-vis time synching?
- Is there an optimal address for time synching?

Pete

Uncheck mark
Automatically adjust clock for daylight saving changes

It's setup to the old daylight saving changes Date
The u.s.a. law makers Made a new daylight saving Date

 

[Charlie+]

it just one Hour for the daylight saving


Pete

Uncheck mark
Automatically adjust clock for daylight saving changes

It's setup to the old daylight saving changes Date
The u.s.a. law makers Made a new daylight saving Date

A small freebie that works beautifully is:
http://www.timesynctool.com/
C+

 

[(PeteCresswell)]

Per Charlie+:

A small freebie that works beautifully is:
http://www.timesynctool.com/

Not being unduly endowed with gray matter, I liked the simplicity of
that.

One question: out of the box, it seems to show four iterations of the
same time server "nettime.pool.ntp.org".

I changed two of the iterations to "time.nist.gov" and
"time.windows.com" respectively.

Did that make sense, or was "pool" an operative word...

 

[Paul]

Per Charlie+:

Not being unduly endowed with gray matter, I liked the simplicity of
that.

One question: out of the box, it seems to show four iterations of the
same time server "nettime.pool.ntp.org".

I changed two of the iterations to "time.nist.gov" and
"time.windows.com" respectively.

Did that make sense, or was "pool" an operative word...

"Pool" consists of hundreds of private time servers,
arranged to sit behind some sort of load balancer. Each
time your machine contacts "pool.ntp.org", a time server
is selected at random from the pool, to service your
request.

Now, if we look at this picture, the "four iterations"
aren't the same. The number in front of the IP address,
as in 2.nettime.pool.ntp.org , makes it a different IP
address than the others. If you did a DNS lookup,
each of those is a different IP address.

http://www.timesynctool.com/nettime.png

On my home router, the NTP in that thing is pointed
only at 2.pool.ntp.org .

As I understand it, each of those is a different pool.
And in fact, the pools don't have equal numbers of
servers in them. One might have 1000 in it, another
700. The idea would be, if whatever functions as a
load balancer for a pool should fail, your time keeping
application will try the next entry, which is a separate
pool of machines, not the same as the first.

If you want to replace one of those with the other servers,
that's fine too. I presume by now, the owners of
"time.nist.gov" and "time.windows.com" have learned
to deal with the crushing load applied to those. Even though
the update rate is many days apart, there are still a lot
of machines pointing to those by default.

The owners of the pool machines, aren't always happy about
the load they see. They are acutely aware they're giving
something away for free. It costs them money for bandwidth
and CPU, to offer that service. And yet, their load (each),
must be a small fraction of the "big boys".

And even if you get the time from one of the big boys,
there is no guarantee it's correct. These systems
have problems from time to time, and can be off by
30 seconds. All it takes is a hardware failure that
someone doesn't notice for a while.

*******

The gadget we had at work for timekeeping/frequency reference,
it didn't have a red warning light that something was wrong.
You had to check the scrolling display on the front, to make
sure it was OK. That one ran off GPS, and GPS makes it
a lot easier to do your own accurate time piece. It's possible
a fair number of the 700 machines in a pool, are each connected
to something like this.

http://gpsinformation.net/main/gpstime.htm

Paul

 

[Hot_Text]

A small freebie that works beautifully is:
http://www.timesynctool.com/
C+

it's is not able to set all the house clocks back

and if I have to walk around setting my Home Clocks
Why not just set to P.C.'s clock by hand too

And it do not remember I know you all here will remind me too!

 

[Paul]

it's is not able to set all the house clocks back

and if I have to walk around setting my Home Clocks
Why not just set to P.C.'s clock by hand too

And it do not remember I know you all here will remind me too!

If you have the right kind of house clocks,
there is no need to set them. They remain
calibrated. The paragraph at the bottom of the
page, mentions bugs in the DST determination,
but that's just like the OSes we use, so no
difference there

http://en.wikipedia.org/wiki/Radio_clock

Paul

 

[J. P. Gilliver (John)]

I seem to recall that the sync will fail if the difference between the
local and remote time is too great. Not sure about that, though. Maybe
you'll find some more informative error messages in the Event Logs.
Maybe your motherboard's BIOS backup battery is dying?

That would seem to be the most likely reason for the drift (which can be
in either direction). They used to nominally last five years; IME they
tend to last much longer, especially if the PC is left connected to the
mains even when not in use (under those circumstances the standby
circuitry, which includes the clock that would otherwise run from the
cell).

It's worth replacing the cell if in any doubt: not just for the clock,
but on a lot of motherboards it supports various BIOS settings. Most
motherboards will auto-reconfigure, but only to safe defaults: if you
have anything unusual, such as non-default cylinder/sector/etc. settings
for your hard drive(s) [unlikely these days], or a RAID array setting,
or tweaked timings for speed, you might lose those.

If it's a laptop/netbook, good luck! If a normal desktop, then it's
almost certain to be a CR2032 (about the shape and size of a 10p piece
[sorry, I don't know the US equivalent]: I think the part number means
20mm diameter 3.2mm thick), and though fiddly isn't that hard to
replace. (If you do it _reasonably_ rapidly, or as I said with the power
still connected [though the PC in standby!!!], settings probably won't
be lost.) They're cheap enough - here poundshops sell them, usually a
card of a few 2032s and a few 2016s.

Not that I know of, but I have noticed that sometimes the time servers
are occasionally unavailable for short whiles.

There's also the possibility of change of protocol supported. I use an
email/news suite of software (Turnpike) that dates from Windows 3.1 days
(it's been updated over the years but); it does the time synching (as
W3.1 didn't have an auto means, I don't think), and over the last few
years some time servers have changed so that Turnpike no longer works
with them. I would _assume_ that servers won't change so that they no
longer support the protocol that XP uses, but you never know; if it does
happen, then obviously just change to one that still does work. (If they
all stop supporting that protocol, then either you'll need a local
translator, or to use one of the many utils that have been mentioned
here that does use a supported protocol.)
No, just lots of servers around the world. One nearest you is likely
(though not always!) to have the lowest latency; it may or may not have
the highest availability.

I have my router set up to sync its time with us.pool.ntp.org every 4
hours, and I have all my local computers set to sync their time with
the router.

I've read the explanation in another post (that this is a pool of time
servers, and requests to it are distributed to even the load); I can't
help thinking that the pool address itself might eventually get too busy
.... (-: [A better - IMO - way of approaching that problem would be to
have the list of servers held, and randomly or otherwise selected from,
locally. There'd have to be a mechanism for updating the list of course
though.]
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

"I'm very peachable, if people know how to peach" - Sir David Attenborough (on
being asked if he was tired of being described as impeachable), on Desert
Island Discs, 2012-1-29.

 

[David H. Lipman]

Last several weeks, my XP box has been coming up with incorrect times -
usually less than current but not on even hour boundaries (i.e. there's
no time zone issue).

Just found it set to 18:50 when the actual time was 19:38.

Opened up "Date and Time Properties", clicked "Update Now"... waited....
and waited... and sure enough, it reported an error while trying to
synch with time.nist.gov.

Flipped over to time.windows.com, and got a successful synch.

I *think* I recall an opposite situation when it started:
time.windows.com was selected but time was wrong. Switched over to
time.nist.gov and it synched.

Three Questions:

- OK, synchs are failing... but why is my PC's clock
getting so far behind?

- I've never had a time synch issue before... ever.
Has something changed vis-a-vis time synching?

- Is there an optimal address for time synching?

Where are you located Geographically ?

 

[(PeteCresswell)]

Per David H. Lipman:

Where are you located Geographically ?

Philadelphia PA, USA

 

[Nil]

I have my router set up to sync its time with us.pool.ntp.org
every 4 hours, and I have all my local computers set to sync their
time with the router.

I've read the explanation in another post (that this is a pool of
time servers, and requests to it are distributed to even the
load); I can't help thinking that the pool address itself might
eventually get too busy ... (-: [A better - IMO - way of
approaching that problem would be to have the list of servers
held, and randomly or otherwise selected from, locally. There'd
have to be a mechanism for updating the list of course though.]

I actually have 4 time servers indicated in my router,

0.pool.ntp.org
1.pool.ntp.org
2.pool.ntp.org
3.pool.ntp.org

This is their recommended setup. Each of those address points to a
different time server that changes hourly. If any one fails for me, the
next one will be tried. That sounds pretty reliable to me and it seems
to have been. They suggest you might also narrow it down to a regional
pool for lower latency. I seem to remember trying that some time ago
and that wasn't as reliable as the world-wide server pool. Any
minuscule difference in accuracy isn't important to me.

 

[Nil]

I actually have 4 time servers indicated in my router,

0.pool.ntp.org
1.pool.ntp.org
2.pool.ntp.org
3.pool.ntp.org

This is their recommended setup. Each of those address points to a
different time server that changes hourly. If any one fails for
me, the next one will be tried. That sounds pretty reliable to me
and it seems to have been. They suggest you might also narrow it
down to a regional pool for lower latency. I seem to remember
trying that some time ago and that wasn't as reliable as the
world-wide server pool. Any minuscule difference in accuracy isn't
important to me.

Ooops! I just checked and see I'm already set up to check the US pool,
not the worldwide:

0.us.pool.ntp.org
1.us.pool.ntp.org
2.us.pool.ntp.org
3.us.pool.ntp.org

 

[Hot_Text]

If you have the right kind of house clocks,
there is no need to set them. They remain
calibrated. The paragraph at the bottom of the
page, mentions bugs in the DST determination,
but that's just like the OSes we use, so no
difference there

Well Paul I have to say you a100% right on

But it's my TV and
DVD Player clocks that do not have to reset
Thank God for that becouse they are not e-z to reset