On Sun, 16 Aug 2009 22:20:34 -0700, isw wrote:
In article ,
Jeff Liebermann wrote:
On Sun, 16 Aug 2009 17:34:37 -0700, David Nebenzahl
wrote:
On 8/16/2009 2:51 PM Meat Plow spake thus:
I agree that for most a minute per month is reasonable but I would
expect the same accuracy as my $29.99 Timex wris****ch which is more
like a second a month.
So that kinda begs the question of why computer mfrs. can't (or won't)
include clocks that are at *least* as accurate as a Timex, no? Wouldn't
a computah be a more compelling reason for a more accurate clock? (I
know, $$$ bottom line, right?)
Because it's difficult. The right way to have done it would have been
to do a function call from an RTC (real time clock) every time some
application needs the actual time.
I don't agree.
That's ok. Nobody ever agrees with me. I'm used to it.
NO CLOCK, running alone, can be really accurate over the
long term. A much better way is to take the output from a crummy,
inaccurate *but low cost* clock and using an external time reference,
synthesize from it a local clock of simply amazing accuracy.
Yep. However, the IBM PC was designed in 1981. At that time, there
were 10 Phase 1 GPS birds, incomplete coverage, and $5,000 receivers.
There were overpriced WWV and WWVB receivers, and no internet. The
best you could do was something synced to the color burst frequency of
a local TV station, assuming they were on 24 hours per day. Your
brilliant hindight is totally correct for a 21st century design, but
would be impossibly expensive in 1981.
My point was that in 1981 IBM had a reasonably accurate clock inside
the IBM PC using a fairly large 14.31818MHz xtal which could have
easily been temperature compensated. There were other computers at
the time that had a seperate stabilized RTC that did it the right way.
However, the IBM PC was originally designed as a home computer, not a
laboratory instrument. The casette tape interface should be a clue.
Using it for industrial, scientific or navigation applications was
probably never considered by the original architects. We're living
with the results today.
NTP solves the problem completely, and at a very low cost (processing
cycles instead of expen$ive hardware). NTP works even if the computer
it's running on has *no RTC* (in the hardware sense) at all. All it
needs is some sort of interrupt generated every N cycles of the
processor clock (N is any integer that produces regular interrupts a few
times a second; the actual interval is not important).
Isaac
--
Jeff Liebermann
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060
http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558