Xtal controlled clocks : What does Toyota know that PC makers don't ??

[me]

Got a house full of PCs and the clocks on all of them are always wrong
- most need monthly adjustment, some weekly.
Wife & I both have Toyotas, and the clocks stay bang on year in, year
out. All these clocks are presumably xtal "locked".
Why do the vehicles do so much better than the peecees ?
M

 

[Jim Thompson]

...

Because they are designed to withstand MIL-temp ranges
and the ones in PCs probably don't even meet COM-temp
specs?

Don't imagine that your two data points define the whole
genre, however. I have examples of computer and auto
clocks that are just the opposite of your anecdotes.

Both of my vehicle (Q45 & Frontier PU) clocks are dead-on. I'm
suspicious that there may be synchronization sent via the AM radio
just like there is clock synchronization transmitted on TV by the PBS
stations.

...Jim Thompson

 

[Don Bruder]

Got a house full of PCs and the clocks on all of them are always wrong
- most need monthly adjustment, some weekly.
Wife & I both have Toyotas, and the clocks stay bang on year in, year
out. All these clocks are presumably xtal "locked".
Why do the vehicles do so much better than the peecees ?

Because the PC clocks are *GENERALLY* driven by a periodic interrupt
generated by the processor or related circuitry, rather than working
directly from a dedicated physical time-base. Commonly, this is a
sub-function of the PC's bus-timing signal, which often isn't anywhere
near a number that's conveniently turned into a "one second has elapsed"
signal. So when your computer does something that "shuts down", "locks
out", or otherwise disturbs the normal interrupt generation/handling
process, it loses track of what time it is. Newer systems generally
include a "correction" mechanism - something along the lines of "If
interrupts were disabled for disk I/O activity, adjust the clock forward
by X amount". If they were disabled for keyboard activity, adjust the
clock forward by Y amount", and so on. Some of the "X"s and "Y"s are
more accurate than others - some are dead on - "A VBL interrupt locks
out the interrupt generation/handling mechanism for precisely "N"
thousandths of a second. Before returning from this interrupt, advance
the RTC (Realtime Clock) by exactly that amount." - or might be
inherently inaccurate estimations - "Disk I/O will never disable
interrupts for less than "W" nor more than "Z" ticks of the clock, so
adjust the clock forward "Z-W/2" ticks every time Disk I/O happens" (AKA
"Take the average").

Other factors include whether the machine has been overclocked (which
will change the base rate at which the clock interrupt is generated,
among other timing alterations), whether your usage requires more or
less adjustment than the algorithm (if any) for adjusting was planned to
compensate for, and similar.

Meanwhile, the digital clock in your toyota is a dedicated device. It
doesn't count on interrupts to generate a "tick" of the clock. It sits
there counting pulses coming off a crystal dedicated to the purpose of
doing nothing but vibrating at the right frequency, doing some math to
convert pulses to clock-time, and displays the result, all without ever
being interrupted, blocked, locked out, or whatever.

Long and short of it: A PC's realtime clock is a compromise design, and
runs on pulses that come at a frequency that may or may not be an
accurate timebase, depending on many factors that the clock has no (and
by its very nature, cannot get) knowledge of, while a "real" clock - one
that does nothing but tell time - operates on pulses that come at
unvarying intervals, and never loses track of time - at least in
relation to itself... It's entirely within the realm of possible to have
two near-identical clocks "drift" with respect to each other because
although they're close to being identical, there's no such thing as two
bits of crystal that resonate at *EXACTLY* the same rate. The difference
in rates may be 38 digits to the right of the decimal, but over the long
haul, that tiny error adds up to a lost or gained second, and sooner or
later, the two clocks drift in comparison to each other.

 

[Tim Auton]

"Jim Thompson" wrote ...

That would be very useful, but I've never heard of such
a thing in 35 years of electronics and broadcast engineering.
(For broadcast radio, that is.)

In the Europe we get time signals sent via RDS (Radio Data System).
That's over broadcast FM radio though, not AM. Isn't RDS used in the
US?


Tim

 

[Jim Thompson]

"Jim Thompson" wrote ...

That would be very useful, but I've never heard of such
a thing in 35 years of electronics and broadcast engineering.
(For broadcast radio, that is.)

I once heard that at least the old, mechanical clocks they
OEMed into vehicles had some mechanism that woluld
slightly adjust the timebase whenever the time was
changed (corrected). So if you were regularly turing
the time back, it would gradually slow down the reference.

That's true. Correcting the time also tweaked the spring tension in
the escapement. I remember those well.

Of course there in AZ, you don't change your clocks back
and forth for the "DST" semi-annual madness. It still causes
havoc with all our corporate cross-site meetings dealing
with those sites that do/don't observe DST.

What do we need with DST? We have enough daylight already ;-)

...Jim Thompson

 

[John G]

Because the PC clocks are *GENERALLY* driven by a periodic interrupt
generated by the processor or related circuitry, rather than working
directly from a dedicated physical time-base. Commonly, this is a
sub-function of the PC's bus-timing signal, which often isn't anywhere
near a number that's conveniently turned into a "one second has elapsed"
signal. So when your computer does something that "shuts down", "locks
out", or otherwise disturbs the normal interrupt generation/handling
process, it loses track of what time it is. Newer systems generally
include a "correction" mechanism - something along the lines of "If
interrupts were disabled for disk I/O activity, adjust the clock forward
by X amount". If they were disabled for keyboard activity, adjust the
clock forward by Y amount", and so on. Some of the "X"s and "Y"s are
more accurate than others - some are dead on - "A VBL interrupt locks
out the interrupt generation/handling mechanism for precisely "N"
thousandths of a second. Before returning from this interrupt, advance
the RTC (Realtime Clock) by exactly that amount." - or might be
inherently inaccurate estimations - "Disk I/O will never disable
interrupts for less than "W" nor more than "Z" ticks of the clock, so
adjust the clock forward "Z-W/2" ticks every time Disk I/O happens" (AKA
"Take the average").

Other factors include whether the machine has been overclocked (which
will change the base rate at which the clock interrupt is generated,
among other timing alterations), whether your usage requires more or
less adjustment than the algorithm (if any) for adjusting was planned to
compensate for, and similar.

Meanwhile, the digital clock in your toyota is a dedicated device. It
doesn't count on interrupts to generate a "tick" of the clock. It sits
there counting pulses coming off a crystal dedicated to the purpose of
doing nothing but vibrating at the right frequency, doing some math to
convert pulses to clock-time, and displays the result, all without ever
being interrupted, blocked, locked out, or whatever.

Long and short of it: A PC's realtime clock is a compromise design, and
runs on pulses that come at a frequency that may or may not be an
accurate timebase, depending on many factors that the clock has no (and
by its very nature, cannot get) knowledge of, while a "real" clock - one
that does nothing but tell time - operates on pulses that come at
unvarying intervals, and never loses track of time - at least in
relation to itself... It's entirely within the realm of possible to have
two near-identical clocks "drift" with respect to each other because
although they're close to being identical, there's no such thing as two
bits of crystal that resonate at *EXACTLY* the same rate. The difference
in rates may be 38 digits to the right of the decimal, but over the long
haul, that tiny error adds up to a lost or gained second, and sooner or
later, the two clocks drift in comparison to each other.

--
Don Bruder - [email protected] <--- Preferred Email - SpamAssassinated.
Hate SPAM? See <http://www.spamassassin.org> for some seriously great info.
I will choose a path that's clear: I will choose Free Will! - N. Peart
Fly trap info pages:

<http://www.sonic.net/~dakidd/Horses/FlyTrap/index.html>

What a load of rubbish!

PC clocks run by themselves in a dedicated battery circuit
that is used to reset the Software clock at each boot up.
If your theory was true my PC would lose about 8 hours a day
because it is turned offf for that time and no amount of
interutps or wait states happen then.

And PCs have had a built in battery clock since the PC AT in
about 19Eighty3 .

 

[Michael Black]

Got a house full of PCs and the clocks on all of them are always wrong
- most need monthly adjustment, some weekly.
Wife & I both have Toyotas, and the clocks stay bang on year in, year
out. All these clocks are presumably xtal "locked".
Why do the vehicles do so much better than the peecees ?
M

Thirty years ago, digital watches and clocks were a new thing, and expensive.
They were treated as precise time pieces, so into the design went concern
for temperature stability, and for adjustment. If you paid a few hundred
dollars for a digital clock or watch, the cost of adjusting the time base
added minimally to the cost.

And thirty years ago, you'd have one of these digital clocks around, and
maybe a digital watch.

But that was on the cusp. A few years later, computers were starting to
go into everything, which meant they could easily add a clock function.
After all, so much of the circuitry was in place, and so was the readout.
But the clocks were an added feature, rather than a precision time piece.

Suddenly, they want to cut out the cost of a trimmer across the crystal,
because that adds money. Besides, the factory doesn't want to pay the
cost of calibration, which suddenly does add significantly to the cost
when the clock is merely a minor part of a piece of equipment, so no sense
paying the cost of components that won't be needed.

Likewise, don't temperature compensate because that will add cost.

Since the clocks are usually part of an existing piece of equipment,
they may be stuck with a crystal frequency that is outright off frequency,
becuase the rest of the circuit needs it. Too minor a difference to
be worth the cost of extra circuitry, but enough to make a difference
over the long run.

Then, the mere fact that we have them all over the place adds problems.
Right in this room, I've got the clock in my computer, a small LCD clock,
a couple of radios that have built in clocks, an LED alarm clock, a vcr and
of course my watch. I don't need all of them, but most of them are simply
part of other things. Yet, because they are all there, which one is right
and which are wrong? There is no way of synchronizing them to the same time.
I set one, and may be off a bit on the seconds. That one over there gets
set at a different time. Plus they may all have slight variations in
their crystal frequency error.

Now, I don't need all those clocks, and I don't need to read down to
the second on all of them. Yet the mere fact that they can't easily be
set to read noon on all of them at the same time helps to create an illusion
that they all keep different times.

So now we have cheap "atomic clocks" controlled by some standard time station
(which one depending on where in the world you are). Virtually nobody needs
that sort of accuracy, yet they are now cheap, I bought one for twenty dollars
last week, so people must be buying them. But they aren't bought for
the accuracy, they are bought because they are self-setting. One doesn't
have to fiddle with them, and one can assume they are at least an exact
time. They are a workaround for the lack of adjustment put into the
average clock.

Michael

 

[Michael Black]

What a load of rubbish!

PC clocks run by themselves in a dedicated battery circuit
that is used to reset the Software clock at each boot up.
If your theory was true my PC would lose about 8 hours a day
because it is turned offf for that time and no amount of
interutps or wait states happen then.

And PCs have had a built in battery clock since the PC AT in
about 19Eighty3 .

But his point is valid.

The "PC" only reads the hardware clock upon booting up, or
if one runs a program to specifically do so. The rest of the time,
it's a real time clock, counting ticks on an interrupt. And as
mentioned, there are times when one cannot count ticks, because
that interrupt has to be turned off.

Leave the computer on long enough, and accumulated error can add up.
Again, this is a matter of how accurately the clock doing the
interrupts is set, how many ticks get missed, and how long the
computer is run before the hardware clock is read again.

The point is that if someone is not familiar with this scheme,
they will note that there is a hardware clock in the computer and
then wonder why the time is wrong.

Michael

 

[Don Bruder]

What a load of rubbish!

PC clocks run by themselves in a dedicated battery circuit
that is used to reset the Software clock at each boot up.
If your theory was true my PC would lose about 8 hours a day
because it is turned offf for that time and no amount of
interutps or wait states happen then.

And PCs have had a built in battery clock since the PC AT in
about 19Eighty3 .

Sorry, but you are wrong. Yes, the real-time-clock (RTC) chip in the
machine is battery backed, and keeps track of things when powered down.
The actual "this is the one the computer reads" clock that drifts is a
"pseudo clock", consisting almost exclusively of software. Once the
machine has booted up and taken the initial setting for the
"pseudo-clock" (really just a "seconds elapsed since boot" counter) from
the RTC chip, the RTC is (barring use of a program designed to go
directly to the RTC for the time, instead of computing what time it's
supposed to be from the seconds-since-startup counterk) ignored until
the next bootup.

 

[John G]

Sorry, but you are wrong. Yes, the real-time-clock (RTC) chip in the
machine is battery backed, and keeps track of things when powered down.
The actual "this is the one the computer reads" clock that drifts is a
"pseudo clock", consisting almost exclusively of software. Once the
machine has booted up and taken the initial setting for the
"pseudo-clock" (really just a "seconds elapsed since boot" counter) from
the RTC chip, the RTC is (barring use of a program designed to go
directly to the RTC for the time, instead of computing what time it's
supposed to be from the seconds-since-startup counterk) ignored until
the next bootup.

form: I'm trashing EVERYTHING that doesn't contain a specific, rotating phrase
in the subject line. Sorry, but spammers have forced me to

take this action.

Yes I will agree with that.
If you had mentioned the battery clock first up I do not
suppose I would have written anyting.