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.

"root" wrote in message
...
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.

Dunno what's causing it, but just put free utility "D4" on the machine, and
set it to correct the time every 5 minutes.

http://download.cnet.com/Dimension-4...-10039998.html

That way, it'll stay close enough all day. One of my workshop machines loses
a coupla minutes a day. D4 runs in the background all the time, and keeps it
right. Needs a connection to the 'net of course, but at least it will put
the time right automatically as soon as you go online, if you don't have a
permanent connection.

Arfa

This is a chronic problem that seems to afflict all computers. I've never
owned a machine whose clock didn't lose time.

Outside of resetting the clock manually, or running a utility that reads the
time from some "correct" source and resets the clock, I know of no solution.

In article ,
William Sommerwerck 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?

This machine checks and updates the time via the net and tells me when it
does it. Usually approx twice a week and four seconds.

--
*If one synchronized swimmer drowns, do the rest have to drown too?

Dave Plowman London SW
To e-mail, change noise into sound.

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.

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.

"Meat Plow" wrote in message
...
On Tue, 11 Aug 2009 10:45:42 +0000 (UTC), 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.

Windows XP and Vista and Linux all have a built in clock sync with a
time server.
Figure out how to set it to update every 6 hours or less.

As far as the hardware is concerned it probably isn't fixable but it's
not the end of the world.

I don't get it. It is just stupid to require an "always up" Internet
connection for any kind of stability. Not to change the subject, B WTF with
my Win 98 machine that keeps trying to connect to NTP servers? I can't find
what process is doing that.

"root" schreef in bericht
...
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.

Well... Guess t's too late for guarantee.

A new battery sometimes solves the problem.

Find the clock/calender chip on your mainboard. If it has a DIP package, it
can be replaced easily. (Hmm... That's to say I can. Don't know about your
skills.) Some SMD-packages can also be replaced but less easily.

Buy, build a battery backup clock that can communicate via the serial port
or an USB one. You will of course need some software too.

Ever saw a high accurate clock on a PCI-card. Don't remember where but still
remember I considered it way too expensive.

petrus bitbyter

On Tue, 11 Aug 2009 10:45:42 +0000 (UTC), root
wrote:

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

Well, that's:
20/1440 = 1.4% accuracy

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

Any particular maker, model, motherboard model?

I've seen the same problem on various machines over the years. On
servers, the problem became sufficiently critical to impliment a fix.
I measured the frequency of the common 14.31818 MHz crystal feeding
the clock oscillator and found it to vary horribly with temperature. I
replaced the crystal with a somewhat better packaged oscillator:
http://parts.digikey.ie/1/1/67619-oscillator-14-31818mhz-full-mxo45t-2c-14m31818.html
That reduced the drift to tolerable levels. Modern motherboards use
different frequencies, but the same principle applies.

For a 14.31818Mhz oscillator to be off 1.4%, it would read about
14.5Mhz. Measure yours.

More difficult to fix are applications that steal clock cycles or beat
up on the processor sufficiently that it misses interrupts. On my old
Pentium III desktop, playing DVD videos was the worst culprit. I also
found some CPU benchmark programs that intentionally made the
processor very busy (and very hot) that ate CPU cycles. I can't offer
any suggestions without knowing the hardware, the system, and the
software mix.

There was also a problem with some old Dell machines, where the BIOS
and the OS were fighting each other for control of the clock. There
was a fix, but I'm too lazy to look for it.

One machine I worked with had a unique problem. When the machine went
into standby, the clock would just stop. When it came out of standby,
it would continue where it left off, losing the time it was in
standby. It was fixed under warranty. I don't recall the vendor.

Oh yeah, check the button battery that backs up the clock. It might
be dead or dying.

--
Jeff Liebermann
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

Meat Plow wrote:

On Tue, 11 Aug 2009 14:55:14 GMT, "JB"
wrote:


"Meat Plow" wrote in message
...
On Tue, 11 Aug 2009 10:45:42 +0000 (UTC), 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.

Windows XP and Vista and Linux all have a built in clock
sync with a time server.
Figure out how to set it to update every 6 hours or
less.

As far as the hardware is concerned it probably isn't
fixable but it's not the end of the world.

I don't get it. It is just stupid to require an "always
up" Internet connection for any kind of stability.

I suppose the unstupid thing would be to replace the
hardware?

(snip)

Begin by finding out which of the two clocks is the bad guy.

The CMOS clock runs continuously, powered from the PC power
supply when available and from the CMOS battery otherwise.
During start-up the O/S reads this hardware clock and uses
this value to initialize the software clock that is the date
and time source until the next startup.

A bum oscillator or low CMOS battery will cause hardware
clock errors and result in wrong-time initialization.

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

In article ,
William Sommerwerck 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 problem with the world is that everyone is a few drinks behind *

Dave Plowman London SW
To e-mail, change noise into sound.

Bryce 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.

In article , root wrote:

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.

This suggests that one of several things is happening.

One is that some device driver in your system is disabling interrupt
processing for a period longer than the kernel's "tick" time value
(usually 1 millisecond, in modern Linux kernels). I've seen this
happen with some disk and network drivers, particularly under periods
of high loading. Some video-card drivers might also have this
problem, particularly when doing highly-intensive rendering.

Another possibility is that your system is configured to use a "high
resolution timer" system to keep track of the time... i.e. a timer
within the CPU itself which ticks along at the basic CPU clock rate,
or some sub-multiple of it. If the motherboard / BIOS / kernel
"thinks" that the CPU is running at a certain clock rate, but the
actual oscillator is a bit slow, then the high-resolution timer will
be running at a rate slower than the kernel's computations expect, and
the clock will drift.

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.

--
Dave Platt 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!

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?

Well, hello, Kali!

On Tue, 11 Aug 2009 10:45:42 +0000 (UTC), 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.
Since you are on this newsgroup, fixing it should be easy. All it
requires is a little soldering. I just checked two fairly modern
motherboards and located the crystal that is associated with the CMOS
clock. Look for a small cylinder lying flat to the board in the
neightborhood of the CMOS battery. That is the crystal that controls
the clock. The error you are seeing is well outside the normal
tolerances for a 'good' (or even a cheap) crystal. Replace it.

If you want high accuracy, it would be necessary to adjust the
frequency by adjusting the parallel capacitor, but normally you should
have an error of less than a minute a week with an uncalibrated
crystal.

PlainBill

wrote in message
...
On Tue, 11 Aug 2009 10:45:42 +0000 (UTC), 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.
Since you are on this newsgroup, fixing it should be easy. All it
requires is a little soldering. I just checked two fairly modern
motherboards and located the crystal that is associated with the CMOS
clock. Look for a small cylinder lying flat to the board in the
neightborhood of the CMOS battery. That is the crystal that controls
the clock. The error you are seeing is well outside the normal
tolerances for a 'good' (or even a cheap) crystal. Replace it.

If you want high accuracy, it would be necessary to adjust the
frequency by adjusting the parallel capacitor, but normally you should
have an error of less than a minute a week with an uncalibrated
crystal.

PlainBill



I think they are similar to watch crystals and are susceptible to vibration,
make sure its glued down.

Dave Platt 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.

In article ,
"George Jetson" wrote:

wrote in message
...
On Tue, 11 Aug 2009 10:45:42 +0000 (UTC), 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.
Since you are on this newsgroup, fixing it should be easy. All it
requires is a little soldering. I just checked two fairly modern
motherboards and located the crystal that is associated with the CMOS
clock. Look for a small cylinder lying flat to the board in the
neightborhood of the CMOS battery. That is the crystal that controls
the clock. The error you are seeing is well outside the normal
tolerances for a 'good' (or even a cheap) crystal. Replace it.

If you want high accuracy, it would be necessary to adjust the
frequency by adjusting the parallel capacitor, but normally you should
have an error of less than a minute a week with an uncalibrated
crystal.

PlainBill



I think they are similar to watch crystals and are susceptible to vibration,
make sure its glued down.

That will make it vibrate just as much as the mobo; if it's just hanging
there by its leads, it may well vibrate less.

Isaac

In article ,
"Dave Plowman (News)" wrote:

In article ,
William Sommerwerck 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

"root" wrote in message
...
Dave Platt 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.

In article ],
isw 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 London SW
To e-mail, change noise into sound.

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.

Ray L. Volts 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.

root wrote:

Bryce 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

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



On Tue, 11 Aug 2009 10:45:42 +0000 (UTC), 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.
HOME PAGE:
http://www.seanet.com/~jasonrnorth
--------------------------------------------------

In article ,
"Dave Plowman (News)" wrote:

In article ],
isw 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

In article ,
"Dave Plowman (News)" wrote:

In article ],
isw 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

In article ],
isw wrote:
In article ,
"Dave Plowman (News)" wrote:

In article ],
isw 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 London SW
To e-mail, change noise into sound.

isw 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.

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

isw 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

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 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

In article ,
Arfa Daily 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 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!

In article ,
"Dave Plowman (News)" wrote:

In article ],
isw wrote:
In article ,
"Dave Plowman (News)" wrote:

In article ],
isw 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

In article ,
"Arfa Daily" 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 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

In article , root
wrote:

isw 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

In article ,
David Nebenzahl wrote:

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

isw 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

On 8/13/2009 10:34 PM isw spake thus:

In article ,
David Nebenzahl wrote:

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

isw 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.

Sounds OK to me, except that I just checked and reset my computah's
clock (I use a little Windoze utility called "NIStime" that gets the
time from NIST); it was off by about 5 minutes. Haven't synched it up
for at least 6 months, so I know my RTCC is at least that accurate.
(Running W2K, so I assume that no software process is adjusting my
clock.) Shouldn't most PC clocks be about that accurate? (Older MB,
forget exactly what, can find out if you're interested.)


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

"Dave Platt" wrote in message
...
In article ,
Arfa Daily 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 AE6EO

Very possible Dave. But on that score, one thing I've found is that when you
decide to go channel hopping on the satellite programmes, it seems to be the
law that the first channel you surf to, will be in a commercial break, then
the next, then the next, then the next, then the .....

And you're right about them going straight into content, with the opening
credits following later. It drives me up the wall as well, when opening
credits are running at the rate of one every 20 seconds or so, and it
doesn't get to "directed by" (always the last one) until 10 minutes - or
more sometimes - into the show. Worst that I've come across in recent years
for annoying openings, was "The Shield". That one had an opening sequence of
what happened in some storyline two seasons ago, as if you can remember, and
then the opening credit sequence started, running over the top of the new
storyline. That I could live with, except that each character name was on a
black screen, so some scene important to the current episode is running, and
for two minutes, you keep getting a black screen with a white name on it,
obliterating what's going on, whilst the sound continues to run, just to
taunt you.

Does anyone know where in the world the school of half-arsed camerawork and
editing techniques is ? Must be a big place, as it seems that networks won't
take on anyone any more, who hasn't graduated from it ... :-)

Arfa

In article ,
Arfa Daily 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 ... :-\

Depends - the actual ad break times are pretty accurate between some of
the companies - the idea being to prevent channel hopping when the ads
come on. You'll just see ads on the others. Hence the way they crash into
the break on progs not made with this schedule in mind. And most of ITV
comes from just one playout centre, so should be synchronised across the
country.
Start times for progs have never been accurately published. They've always
been approximate - apart from on some data points in the evening.

--
*The problem with the gene pool is that there is no lifeguard *

Dave Plowman London SW
To e-mail, change noise into sound.

In article ,
Dave Platt wrote:
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.

Most PVRs allow you to set a buffer period at start and finish of the
prog. But if only the EPG sent out a flag for the *actual* start and
finish.

--
*If a mute swears, does his mother wash his hands with soap?

Dave Plowman London SW
To e-mail, change noise into sound.

In article ],
isw wrote:
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.

Dunno the actual process, but I have a radio controlled clock next to the
computer - and that always agrees as close as I can tell to the time
signal off analogue radio - but never *exactly* with the computer one. Of
course this could be some delay within the computer. I have two computers
here - an elderly RISC OS one and a newish PC, and it applies to both.

--
*The more people I meet, the more I like my dog.

Dave Plowman London SW
To e-mail, change noise into sound.