WTF with my computer clock?

[isw]

In article <5089421807dave@davenoise.co.uk>,
"Dave Plowman (News)" <dave@davenoise.co.uk> wrote:

In article <h5rvp4$o1v$1@news.eternal-september.org>,
William Sommerwerck <grizzledgeezer@comcast.net> wrote:
This is a chronic problem that seems to afflict all computers. I've
never owned a machine whose clock didn't lose time.

Well, yes, but surely only a few seconds a day?

Please don't call me surely.

Ok. How about Kali? The goddess of time?

I should have pointed out that 20 minutes a day is, indeed, unusual. But
computer clocks are notoriously inaccurate. And I've never seen one that
gained time.

Think you're right there. So perhaps there's a reason for it. They're
never going to be *that* accurate given the crystals they use.

The bottom line is that unless you synchronize it with a "reference"
timekeeper, it *will not* run at the correct rate. The only question is
how fast it will drift. NTP clients (*good* ones) can deal with the
problem amazingly well, but only if the host's network connection is
pretty much continuous and the host essentially does not sleep.

Isaac

 

[JB]

"root" <NoEMail@home.org> wrote in message
news:h5t9op$ac0$1@news.albasani.net...

Dave Platt <dplatt@radagast.org> wrote:
You may be able to resolve the problem by using the NTP daemon
(available in most distributions). It has two benefits:

- It can set, and resynchonize the system clock via periodic queries of
highly-stable time servers, via the Internet. This gives you a
very reliable time-sync to start with.

- It can calculate the amount of "drift" that your system's local
clock has (by comparing the system clock-run rate against the rate
deduced by querying NTP servers), and can then instruct the kernel
to compensate for this drift (i.e. "tweaking" the kernel's own
clock-update algorithm). This compensation helps keep the clock
correct, in between the larger adjustements that the NTP daemon
makes when it queries Internet time servers.


Thanks for the advice Dave, I started ntpd and will see how that
works.

You might also dig a little deeper into the support site for your machine
and see if there isn't a workaround or update.

 

[Dave Plowman (News)]

In article <isw-2A2300.21493111082009@[216.168.3.50]>,
isw <isw@witzend.com> wrote:

The bottom line is that unless you synchronize it with a "reference"
timekeeper, it *will not* run at the correct rate. The only question is
how fast it will drift. NTP clients (*good* ones) can deal with the
problem amazingly well, but only if the host's network connection is
pretty much continuous and the host essentially does not sleep.

My machine is switched off when not in use. The prog which synchronises
the machine time to the network runs at boot. It also tells you what it's
done. And perhaps a couple of times a week it adjusts the time by a few
seconds. So the internal clock is near as accurate as an ordinary quartz
battery one. I'm not quite sure just when it would matter if the internal
clock was a few seconds out anyway.

--
*How's my driving? Call 999*

Dave Plowman dave@davenoise.co.uk London SW
To e-mail, change noise into sound.

 

[Ray L. Volts]

root wrote:

The damned thing loses about 20 minutes/day and has
so since the machine was new about 3 years ago.

My guess is that it isn't fixable, but maybe you
have some ideas.

TIA.

This thread reminds me of an old Columbo movie.
As I recall, the murderer had reset his PC clock so that certain data
would be erroneously timestamped while his PC was used during his
absence -- thus providing his alibi later. I don't recall how Columbo
realized this bit of trickery had taken place, but, being Columbo, he
did. Nowadays, the culprit would need to remember to also keep the
machine from syncing with online time servers!

Not particularly helpful to the OP, just throwing it out there as an
amusing tangent.

More on point, I have an old W2K machine -- Abit KT-7 RAID mobo that I
had to recap -- that loses about 10mins every couple weeks. It isn't a
"mission-critical" machine and isn't online often, but I don't mind
occasionally resetting its clock.

 

[Meat Plow]

On Tue, 11 Aug 2009 19:28:43 +0000 (UTC), root
<NoEMail@home.org>wrote:

Bryce <none@invalid.invalid> wrote:

If the CPU misses servicing the clock interrupt or other bad
stuff, the operating system's idea of time will suffer, but
the hardware clock keeps right on ticking.

So, if you're losing time without a reboot, the CMOS is
innocent and the O/S and CPU aren't doing the right dance.
If the time is wrong from the gitgo, then the HW clock is
the culprit.

Bryce

Good points. The computer loses time when it is running.
It is the way the time is updated by the cpu/kernel.
I am running linux.

Plenty of goop to read regarding speific linux kernel modules flubbing
up real time clock updates. Should have mentioned an OS in the first
place.

 

[root]

Ray L. Volts <raylvolts@REMOVECAPSgmail.com> wrote:

More on point, I have an old W2K machine -- Abit KT-7 RAID mobo that I
had to recap -- that loses about 10mins every couple weeks. It isn't a
"mission-critical" machine and isn't online often, but I don't mind
occasionally resetting its clock.

Once a week I run a cron program that streamrips a radio program. I want
to get the start of the program [prairie home companion]. At 20 minutes
a day time loss, I have to sync the time just before I want to start
recording. So far I have set two additional cron jobs, one at the start
of the particular day, then one 15 minutes before the program begins.
It is like using a sledge hammer for everything I do.

 

[Bryce]

root wrote:

Bryce <none@invalid.invalid> wrote:

If the CPU misses servicing the clock interrupt or other
bad stuff, the operating system's idea of time will
suffer, but the hardware clock keeps right on ticking.

So, if you're losing time without a reboot, the CMOS is
innocent and the O/S and CPU aren't doing the right
dance. If the time is wrong from the gitgo, then the HW
clock is the culprit.

Bryce

Good points. The computer loses time when it is running.
It is the way the time is updated by the cpu/kernel.
I am running linux.

Me too. Have a look at man hwclock.

Maybe running hwclock -r to resync the system time to the
CMOS (RTC) clock every so often as a cron job would suffice.
hwclock does tweaking to counter long-term drift in the RTC.
Not as spiffy as syncing with a time server, but no internet
connection needed.

Bryce

 

[JR North]

Beatnik internet clock
www.somedec.com/downloads/
JR



On Tue, 11 Aug 2009 10:45:42 +0000 (UTC), root <NoEMail@home.org>
wrote:

The damned thing loses about 20 minutes/day and has
so since the machine was new about 3 years ago.

My guess is that it isn't fixable, but maybe you
have some ideas.

TIA.
HOME PAGE:

http://www.seanet.com/~jasonrnorth
--------------------------------------------------

 

[isw]

In article <50898def35dave@davenoise.co.uk>,
"Dave Plowman (News)" <dave@davenoise.co.uk> wrote:

>,
isw <isw@witzend.com> wrote:
The bottom line is that unless you synchronize it with a "reference"
timekeeper, it *will not* run at the correct rate. The only question is
how fast it will drift. NTP clients (*good* ones) can deal with the
problem amazingly well, but only if the host's network connection is
pretty much continuous and the host essentially does not sleep.

My machine is switched off when not in use. The prog which synchronises
the machine time to the network runs at boot. It also tells you what it's
done. And perhaps a couple of times a week it adjusts the time by a few
seconds. So the internal clock is near as accurate as an ordinary quartz
battery one. I'm not quite sure just when it would matter if the internal
clock was a few seconds out anyway.

That just jams the clock to the correct time once in a while. In between
those times the clock still runs at the same rate it always did, which
is not correct.

What the NTP process does is essentially to monitor the local clock
compared to a reference to understand just what its errors are, and
synthesize a "perfect" clock from it. The synthesized clock can remain
within a few microseconds (or better) of a reference timekeeper all the
time.

Isaac

 

[isw]

In article <50898def35dave@davenoise.co.uk>,
"Dave Plowman (News)" <dave@davenoise.co.uk> wrote:

>,
isw <isw@witzend.com> wrote:
The bottom line is that unless you synchronize it with a "reference"
timekeeper, it *will not* run at the correct rate. The only question is
how fast it will drift. NTP clients (*good* ones) can deal with the
problem amazingly well, but only if the host's network connection is
pretty much continuous and the host essentially does not sleep.

My machine is switched off when not in use. The prog which synchronises
the machine time to the network runs at boot. It also tells you what it's
done. And perhaps a couple of times a week it adjusts the time by a few
seconds. So the internal clock is near as accurate as an ordinary quartz
battery one. I'm not quite sure just when it would matter if the internal
clock was a few seconds out anyway.

If you're just an ordinary user, it probably doesn't. If you are the
telephone company, or a television broadcaster, though, things really do
work a lot better when the digital signals carried by your network all
are at precisely the same bitrate, no matter where they come from.

A GPS receiver feeding a UNIX box running NTP can give you a local
timebase accurate to about one part in ten (American) billions.

Isaac

 

[Dave Plowman (News)]

In article <isw-244FC5.00182613082009@[216.168.3.50]>,
isw <isw@witzend.com> wrote:

In article <50898def35dave@davenoise.co.uk>,
"Dave Plowman (News)" <dave@davenoise.co.uk> wrote:

In article <isw-2A2300.21493111082009@[216.168.3.50]>,
isw <isw@witzend.com> wrote:
The bottom line is that unless you synchronize it with a "reference"
timekeeper, it *will not* run at the correct rate. The only question is
how fast it will drift. NTP clients (*good* ones) can deal with the
problem amazingly well, but only if the host's network connection is
pretty much continuous and the host essentially does not sleep.

My machine is switched off when not in use. The prog which
synchronises the machine time to the network runs at boot. It also
tells you what it's done. And perhaps a couple of times a week it
adjusts the time by a few seconds. So the internal clock is near as
accurate as an ordinary quartz battery one. I'm not quite sure just
when it would matter if the internal clock was a few seconds out
anyway.

If you're just an ordinary user, it probably doesn't.

Indeed.

If you are the
telephone company, or a television broadcaster, though, things really do
work a lot better when the digital signals carried by your network all
are at precisely the same bitrate, no matter where they come from.

Right. At one time TV stations etc had their own accurate pulse generator
referenced to the national standard. Here in the UK it was IIRC from the
National Physics Laboratory.

A GPS receiver feeding a UNIX box running NTP can give you a local
timebase accurate to about one part in ten (American) billions.

But I suppose things move on. ;-)

Trouble is for most is just how accurate is the NTP time from your ISP?

Isaac

--
*If tennis elbow is painful, imagine suffering with tennis balls *

Dave Plowman dave@davenoise.co.uk London SW
To e-mail, change noise into sound.

 

[root]

isw <isw@witzend.com> wrote:

What the NTP process does is essentially to monitor the local clock
compared to a reference to understand just what its errors are, and
synthesize a "perfect" clock from it. The synthesized clock can remain
within a few microseconds (or better) of a reference timekeeper all the
time.

Isaac

Maybe that works if you leave the computer on all the time. I started
the ntpd daemon early in the morning and by late afternoon the time
was, once again, way the hell off. Since I only care one time, one
day a week what the time is I have set up crontab entries to do the
job.

 

[David Nebenzahl]

On 8/13/2009 4:58 AM root spake thus:

isw <isw@witzend.com> wrote:

What the NTP process does is essentially to monitor the local clock
compared to a reference to understand just what its errors are, and
synthesize a "perfect" clock from it. The synthesized clock can remain
within a few microseconds (or better) of a reference timekeeper all the
time.

Maybe that works if you leave the computer on all the time. I started
the ntpd daemon early in the morning and by late afternoon the time
was, once again, way the hell off. Since I only care one time, one
day a week what the time is I have set up crontab entries to do the
job.

I see the problem, that seems to have been missed by those suggesting a
software kluge that periodically stuffs the clock with the right value.

Here's an idea I haven't seen in this thread yet: If you're really
interested in getting to the bottom of this problem, how about trying to
determine whether it's the actual clock (RTCC hardware) that's off, or
whether the OS is missing interrupts or there's some other software problem?

How about booting the computah under some other OS, say Windoze or even
DOS, and running a utility that checks the RTCC for accuracy? (Don't
know of any, but I'm ass-uming that there are lots of such utilities out
there. Maybe there's even one for Linux.) That way you could know
whether the clock needs to be tweaked (new crystal as suggested by
others), or whether it's an OS problem.

Just an idea.


--
Found--the gene that causes belief in genetic determinism

 

[Meat Plow]

On Thu, 13 Aug 2009 10:15:46 -0700, David Nebenzahl
<nobody@but.us.chickens>wrote:

On 8/13/2009 4:58 AM root spake thus:

isw <isw@witzend.com> wrote:

What the NTP process does is essentially to monitor the local clock
compared to a reference to understand just what its errors are, and
synthesize a "perfect" clock from it. The synthesized clock can remain
within a few microseconds (or better) of a reference timekeeper all the
time.

Maybe that works if you leave the computer on all the time. I started
the ntpd daemon early in the morning and by late afternoon the time
was, once again, way the hell off. Since I only care one time, one
day a week what the time is I have set up crontab entries to do the
job.

I see the problem, that seems to have been missed by those suggesting a
software kluge that periodically stuffs the clock with the right value.

Here's an idea I haven't seen in this thread yet: If you're really
interested in getting to the bottom of this problem, how about trying to
determine whether it's the actual clock (RTCC hardware) that's off, or
whether the OS is missing interrupts or there's some other software problem?

How about booting the computah under some other OS, say Windoze or even
DOS, and running a utility that checks the RTCC for accuracy? (Don't
know of any, but I'm ass-uming that there are lots of such utilities out
there. Maybe there's even one for Linux.) That way you could know
whether the clock needs to be tweaked (new crystal as suggested by
others), or whether it's an OS problem.

Just an idea.

I suggested booting Hiren's a few days ago. Also the OP could just
boot into the CMOS setup and watch the clock there. Haven't needed to
test any RTC hardware here seeing how SNTP has been around since the
mid 80's and is among one of the oldest network protocols. Personal
computer clocks are notoriously inaccurate, always have been. SNTP was
developed for the needs of networked servers where precision time
keeping was desired. SNTP daemons have been built into Windows OS for
nearly a decade.

 

[Arfa Daily]

If you are the
telephone company, or a television broadcaster, though, things really do
work a lot better when the digital signals carried by your network all
are at precisely the same bitrate, no matter where they come from.

Right. At one time TV stations etc had their own accurate pulse generator
referenced to the national standard. Here in the UK it was IIRC from the
National Physics Laboratory.


Dave Plowman dave@davenoise.co.uk London SW
To e-mail, change noise into sound.

I reckon that TV companies must now use these laptops with very rough RTCs !
Have you noticed that now programme material is not networked from one
region into some or all of the others, and adverts are no longer 'local',
there is not any need for accurate cueing points around the network, so
advertised starting times are not even nodded at ? I checked the starting
times of about half a dozen programmes tonight, using the teletext clock,
which I believe to be accurate, and not a single one started within 1 minute
of the correct time, and a couple of them were off by several minutes. Just
another manifestation of declining standards throughout the civilised world
.... :-\

Arfa

 

[Dave Platt]

In article <zm2hm.283768$Sn5.199463@newsfe26.ams2>,
Arfa Daily <arfa.daily@ntlworld.com> wrote:

I reckon that TV companies must now use these laptops with very rough RTCs !
Have you noticed that now programme material is not networked from one
region into some or all of the others, and adverts are no longer 'local',
there is not any need for accurate cueing points around the network, so
advertised starting times are not even nodded at ? I checked the starting
times of about half a dozen programmes tonight, using the teletext clock,
which I believe to be accurate, and not a single one started within 1 minute
of the correct time, and a couple of them were off by several minutes. Just
another manifestation of declining standards throughout the civilised world
... :-\

At least some of that starting-time error seems to be a deliberate
policy by the stations/networks. By de-synchronizing a network's
start times from those of its competitors, the network can make
channel-surfing less attractive to the viewer... by the time you
finish watching a show on that network, the shows on the other
networks have already started and you'd miss something by surfing away.

It's a frightful bother who use DVRs and VCRs to time-shift programs...
losing the first or last minute of a show is quite common.

--
Dave Platt <dplatt@radagast.org> AE6EO
Friends of Jade Warrior home page: http://www.radagast.org/jade-warrior
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!

 

[isw]

In article <508a17af7ddave@davenoise.co.uk>,
"Dave Plowman (News)" <dave@davenoise.co.uk> wrote:

>,
isw <isw@witzend.com> wrote:
In article <50898def35dave@davenoise.co.uk>,
"Dave Plowman (News)" <dave@davenoise.co.uk> wrote:

In article <isw-2A2300.21493111082009@[216.168.3.50]>,
isw <isw@witzend.com> wrote:
The bottom line is that unless you synchronize it with a "reference"
timekeeper, it *will not* run at the correct rate. The only question is
how fast it will drift. NTP clients (*good* ones) can deal with the
problem amazingly well, but only if the host's network connection is
pretty much continuous and the host essentially does not sleep.

My machine is switched off when not in use. The prog which
synchronises the machine time to the network runs at boot. It also
tells you what it's done. And perhaps a couple of times a week it
adjusts the time by a few seconds. So the internal clock is near as
accurate as an ordinary quartz battery one. I'm not quite sure just
when it would matter if the internal clock was a few seconds out
anyway.

If you're just an ordinary user, it probably doesn't.

Indeed.

If you are the
telephone company, or a television broadcaster, though, things really do
work a lot better when the digital signals carried by your network all
are at precisely the same bitrate, no matter where they come from.

Right. At one time TV stations etc had their own accurate pulse generator
referenced to the national standard. Here in the UK it was IIRC from the
National Physics Laboratory.

A GPS receiver feeding a UNIX box running NTP can give you a local
timebase accurate to about one part in ten (American) billions.

But I suppose things move on. ;-)

Trouble is for most is just how accurate is the NTP time from your ISP?

It doesn't come "from" my ISP; more like "through" it. And if I have a
decent NTP client setup, my computer's clock (not the hardware, but the
software one the OS provides to applications) will run at *precisely*
the correct rate in the long term (the longer the term, the greater the
precision), and will provide the proper epoch within a couple of
microseconds or so -- maybe better. The rate be very, very close for
shorter intervals. The place where it will not do so well is with very
short measures because the jitter may be a bit high compared to, say, a
rubidium clock.

Isaac

 

[isw]

In article <zm2hm.283768$Sn5.199463@newsfe26.ams2>,
"Arfa Daily" <arfa.daily@ntlworld.com> wrote:

If you are the
telephone company, or a television broadcaster, though, things really do
work a lot better when the digital signals carried by your network all
are at precisely the same bitrate, no matter where they come from.

Right. At one time TV stations etc had their own accurate pulse generator
referenced to the national standard. Here in the UK it was IIRC from the
National Physics Laboratory.


Dave Plowman dave@davenoise.co.uk London SW
To e-mail, change noise into sound.


I reckon that TV companies must now use these laptops with very rough RTCs !
Have you noticed that now programme material is not networked from one
region into some or all of the others, and adverts are no longer 'local',
there is not any need for accurate cueing points around the network, so
advertised starting times are not even nodded at ? I checked the starting
times of about half a dozen programmes tonight, using the teletext clock,
which I believe to be accurate, and not a single one started within 1 minute
of the correct time, and a couple of them were off by several minutes.

That's not the place where television needs precise time; it involves
the generation and dissemination of NTSC or PAL in the past, or MPEG
multiplexes in the present, not the *content* carried by those signals.

There's pretty good reason to suspect that broadcasters purposely offset
the starting times of their programs precisely to make it less desirable
for you to change channels during the interval -- if you can never watch
both the end of one program and the beginning of another, you're less
likely to do it. Note that a lot of contemporary shows start directly
with some dialog and action, while the title and intro follow on a bit
later. You miss the first few seconds, you lose. Same with the ends of
shows.

Isaac

 

[isw]

In article <h60v4c$hva$1@news.albasani.net>, root <NoEMail@home.org>
wrote:

isw <isw@witzend.com> wrote:

What the NTP process does is essentially to monitor the local clock
compared to a reference to understand just what its errors are, and
synthesize a "perfect" clock from it. The synthesized clock can remain
within a few microseconds (or better) of a reference timekeeper all the
time.

Isaac

Maybe that works if you leave the computer on all the time.

And that is exactly what NTP expects/needs.

I started
the ntpd daemon early in the morning and by late afternoon the time
was, once again, way the hell off. Since I only care one time, one
day a week what the time is I have set up crontab entries to do the
job.

It's also necessary to have a means to couple the output of the
disciplined clock to other apps that do things like run the clock on the
screen. Honestly, I'm not familiar with that; I've only used NTP to
synchronize things on embedded systems where we had control of all the
processes.

I do know that it can take quite a while (few dozen hours??) of
continuous operation before ntpd gets things figured out, and if the
host goes offline or sleeps it's necessary to start all over again. If
you read the man page, I think you'll see that there are ways to force a
faster, less precise, synch.

For more than you (probably) ever wanted to know about it, google up RFC
1305 and RFC 1128b.

ISaac

 

[isw]

In article <4a844907$0$7473$822641b3@news.adtechcomputers.com>,
David Nebenzahl <nobody@but.us.chickens> wrote:

On 8/13/2009 4:58 AM root spake thus:

isw <isw@witzend.com> wrote:

What the NTP process does is essentially to monitor the local clock
compared to a reference to understand just what its errors are, and
synthesize a "perfect" clock from it. The synthesized clock can remain
within a few microseconds (or better) of a reference timekeeper all the
time.

Maybe that works if you leave the computer on all the time. I started
the ntpd daemon early in the morning and by late afternoon the time
was, once again, way the hell off. Since I only care one time, one
day a week what the time is I have set up crontab entries to do the
job.

I see the problem, that seems to have been missed by those suggesting a
software kluge that periodically stuffs the clock with the right value.

Here's an idea I haven't seen in this thread yet: If you're really
interested in getting to the bottom of this problem, how about trying to
determine whether it's the actual clock (RTCC hardware) that's off, or
whether the OS is missing interrupts or there's some other software problem?

How about booting the computah under some other OS, say Windoze or even
DOS, and running a utility that checks the RTCC for accuracy? (Don't
know of any, but I'm ass-uming that there are lots of such utilities out
there. Maybe there's even one for Linux.) That way you could know
whether the clock needs to be tweaked (new crystal as suggested by
others), or whether it's an OS problem.

Just an idea.

As I said earlier, if the local clock (crystal, whatever) is
free-running (not synced to a standard reference using e.g. ntpd), it
*will not* stay accurate because it *cannot* be running at precisely the
proper rate all the time. No matter how often you set it. No matter how
often you tweak that little capacitor (which is very likely *not there*
to tweak in the first place. You can *never* get it "right on". The
question is not whether it is ever "correct", but only how fast it
diverges from "correct" whenever you stop messing with it. The
brilliance and elegance of NTP is that it can take that crappy,
imprecise, piece of temperature-sensitive quartz, and from it synthesize
an amazingly precise timekeeper.

Isaac