clock problem
Big Bill
Ubuntu 8.10 on a TBird 900.
When we start the machine, the time is correct but it looses time during
the day, up to 10 minutes. If we shut down the machine and restart, the
time is correct again.
Any idea ?
Thanks
notbob
>
> When we start the machine, the time is correct but it looses time during
> the day, up to 10 minutes. If we shut down the machine and restart, the
> time is correct again.
>
> Any idea ?
There are several solutions, including running your own time server.
My approach is to run an hourly cron job bash script. It looks like
this:
#!/bin/sh
/usr/sbin/ntpdate 164.67.62.194
....the ip address being a server local to my time zone (mountain).
Not sure how your distro handles cron, but this is slackware 13.
nb
AZ Nomad
>Any idea ?
bad motherboard. the timer tick frequency is off
You could set up ntp-client to keep it corrected. I think it is even
supposed to be smart enough that it'll calculate the drift and apply
automatic corrections.
jan olieslagers
> On 2009-11-09, Big Bill <billl...@gmail.com> wrote:
>
>> When we start the machine, the time is correct but it looses time during
>> the day, up to 10 minutes. If we shut down the machine and restart, the
>> time is correct again.
>>
>> Any idea ?
>
> There are several solutions, including running your own time server.
> My approach is to run an hourly cron job bash script. It looks like
> this:
>
> #!/bin/sh
> /usr/sbin/ntpdate 164.67.62.194
>
> ....the ip address being a server local to my time zone (mountain).
That will of course work, but it is not a solution, it's a workaround.
BTW no need to limit your NTP server to your local time zone - time
keeps good over distances.
The real question is: why does the OS loose time where the hardware doesn't.
KA
Big Bill
>
>> Any idea ?
> bad motherboard. the timer tick frequency is off
Brek. Bad news.
>
> You could set up ntp-client to keep it corrected. I think it is even
> supposed to be smart enough that it'll calculate the drift and apply
> automatic corrections.
Thanks
notbob
> That will of course work, but it is not a solution, it's a workaround.
That may be the dumbest statement I've heard ....in the last 5 mins.
> The real question is: why does the OS loose time where the hardware doesn't.
Definintely the dumbest statement I've heard ....in the last 6 mins.
nb
Joe Pfeiffer
I've got no idea why you regard either of these as dumb. I'll toss in a
further (dumb?) remark: question is why his machine is losing
unacceptable amounts of time when nobody else is seeing it: dropping
interrupts?
--
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin)
notbob
> I've got no idea why you regard either of these as dumb. I'll toss in a
> further (dumb?) remark: question is why his machine is losing
> unacceptable amounts of time when nobody else is seeing it: dropping
> interrupts?
Piece of crap?
nb
root
I had a lot of trouble with my clock until I was directed
to adjtimex. See the man page. I was able to adjust the
tick value to a point where my clock was only off a
couple of seconds/day. After setting the tick value you
can use the ntpd daemon for more accurate timekeeping.
Moe Trin
<1btyx3b...@snowball.wb.pfeifferfamily.net>, Joe Pfeiffer wrote:
>I'll toss in a further (dumb?) remark: question is why his machine
>is losing unacceptable amounts of time when nobody else is seeing it:
>dropping interrupts?
When shut down (or sleeping/hibernating), the clock is set on
(re-)awakening from the CMOS or BIOS clock.
When the system is running, the clock is run from a periodic hardware
interrupt routine. Look at the content of '/proc/interrupts' as
close to ten seconds apart as you can, and pay attention to the
difference in the counts.
Another difference is the oscillator used to generate these
interrupts. The CMOS/BIOS clock is run from it's own oscillator
(often a crystal or tuning fork of 32768 Hertz). The interrupts
are counting a different oscillator - formerly a 1.8432 MHz
crystal that also supplied timing to the serial "baud" clock,
but now more commonly the same oscillator used to clock the CPU.
If the system clock GAINS or looses time, the cause may be a bad
timing oscillator. These _normally_ have a setting error of up to 50
parts/million, and may drift as a function of temperature, vibration
or supply voltage by up to another 50 parts/million. The worst case
error should be less than 100 ppm, or 8.64 seconds per day.
The other error source is "dropped interrupts". Interrupts are set to
be "edge" sensitive, but if the system is prevented from responding
to the interrupt (system to busy, or a poorly written program
intentionally masking the interrupts for one selfish reason or
another), the system time won't be updated and will fall behind. The
later cause is _somewhat_ less common using software provided by the
distribution (and more common with "third party" software found under
a rock somewhere on the Internet). "System to busy" is an operator
problem - visible using 'top' on the system load indications seen on
a 'uptime' output.
Old guy
Moe Trin
>notbob schreef:
>> My approach is to run an hourly cron job bash script. It looks like
>> this:
>>
>> #!/bin/sh
>> /usr/sbin/ntpdate 164.67.62.194
>>
>> ....the ip address being a server local to my time zone (mountain).
[compton ~]$ host 164.67.62.194
194.62.67.164.IN-ADDR.ARPA domain name pointer tick.ucla.edu
[compton ~]$
Amazing! The earthquakes must be worse than I remember if Los
Angeles is now in the Mountain time zone.
>That will of course work,
FSRather_strangeVO "work"
>but it is not a solution, it's a workaround.
It hides some of the indications of the problem.
>BTW no need to limit your NTP server to your local time zone - time
>keeps good over distances.
Network distances usually have little relationship to physical
distances. I'm in Phoenix, Arizona, and UCLA (360 miles/600 KM
distant) is closer in hop-count than Arizona State University
in the next town (about 10 miles/16 KM).
Few people actually _need_ absolute time accurate to millionths of a
second. Even an error of a second or two isn't going to matter and
won't be noticed.
>The real question is: why does the OS loose time where the hardware
>doesn't.
Because they are not looking at the same things. The "hardware"
time is a 32768 Hertz tuning fork or crystal oscillator that
updates once per second. O/S time is an interrupt driven routine
updated at a kernel compile setting rate (100 to 1000 times per
second) running from a different oscillator. Either timing source
oscillator should be accurate to better than 10 seconds a day. An
error of minutes per day LOST usually means interrupt blocking or
loss due to bad software, or an over-loaded system with excessive
eye-candy.
Old guy
Steve Wampler
> When we start the machine, the time is correct but it looses time during
> the day, up to 10 minutes. If we shut down the machine and restart, the
> time is correct again.
As you've probably noticed from the responses, there could be a number
of reasons. Another possible solution (it's what I had to do on one
of my machines) is to select a different clocksource in the kernel
when booting. My grub.conf has the kernel parameter:
clocksource=hpet
Before I did this, I saw virtually identical behavior to yours, even
when running ntpd (ntpd could not keep the time accurate). Now nptd
can keep this machine accurate and sync'd with my others. None of
the other (5) machines needed this fix, incidentally.
Moe Trin
<fluos6x...@weaver.tuc.noao.edu>, Steve Wampler wrote:
>Big Bill wrote:
>> When we start the machine, the time is correct but it looses time
>> during the day, up to 10 minutes.
>As you've probably noticed from the responses, there could be a number
>of reasons. Another possible solution (it's what I had to do on one
>of my machines) is to select a different clocksource in the kernel
>when booting. My grub.conf has the kernel parameter:
>
> clocksource=hpet
Most of the reports I've heard of this have mentioned wildly
erratic time - as it's varying if the clock speed is switching.
>Before I did this, I saw virtually identical behavior to yours, even
>when running ntpd (ntpd could not keep the time accurate).
s/could/would/
Grab a text version of RFC1305
1305 Network Time Protocol (Version 3) Specification, Implementation
and Analysis. D. Mills. March 1992. (Format: TXT=307085,
PDF=442493 bytes) (Obsoletes RFC0958, RFC1059, RFC1119)
(Status: DRAFT STANDARD)
and look around line 2756 (middle of first paragraph of the section
"Implementation Issues"). It's a sanity check, and NTP won't mess
with a clock more than a thousand seconds (00:16:40) out of sync, or
one that is drifting excessively (500 ppm - man ntpd).
Old guy
root
>
> Grab a text version of RFC1305
>
> 1305 Network Time Protocol (Version 3) Specification, Implementation
> and Analysis. D. Mills. March 1992. (Format: TXT=307085,
> PDF=442493 bytes) (Obsoletes RFC0958, RFC1059, RFC1119)
> (Status: DRAFT STANDARD)
>
> and look around line 2756 (middle of first paragraph of the section
> "Implementation Issues"). It's a sanity check, and NTP won't mess
> with a clock more than a thousand seconds (00:16:40) out of sync, or
> one that is drifting excessively (500 ppm - man ntpd).
>
> Old guy
If your drift is so bad that ntpd will not correct, then
you have to use adjtimex to set the tick value to bring
the clock close enough for ntpd to take over.
Steve Wampler
> Most of the reports I've heard of this have mentioned wildly erratic
> time - as it's varying if the clock speed is switching.
>
>>Before I did this, I saw virtually identical behavior to yours, even
>>when running ntpd (ntpd could not keep the time accurate).
>
> s/could/would/
Right - poor use of English on my part. On the affected system,
the clock drift was too high and ntpd wouldn't sync up. I've had
no problems since switching the clocksource to hpet. This is an
'older' Opteron dual processor (single cores) that doesn't switch
clock speeds. I don't remember seeing the problem back when the
machine was new, but couldn't tell you if the problem has simply
gotten worse over time, or coincided with a kernel upgrade.
James Michael Fultz
> If your drift is so bad that ntpd will not correct, then
> you have to use adjtimex to set the tick value to bring
> the clock close enough for ntpd to take over.
Or invoke ntpd with the '-g' option.
--
James Michael Fultz <xy...@sent.as.invalid>
Remove this part when replying ^^^^^^^^
Big Bill
>
>> The real question is: why does the OS loose time where the hardware
>> doesn't.
>
> Because they are not looking at the same things. The "hardware"
> time is a 32768 Hertz tuning fork or crystal oscillator that
> updates once per second. O/S time is an interrupt driven routine
> updated at a kernel compile setting rate (100 to 1000 times per
> second) running from a different oscillator. Either timing source
> oscillator should be accurate to better than 10 seconds a day. An
> error of minutes per day LOST usually means interrupt blocking or
> loss due to bad software, or an over-loaded system with excessive
> eye-candy.
Sorry I didn't answer back to anybody but I'm down with the H1N1 and I
feel like i've been hit by a train and I can't go to that computer which
is my mother's one.
Her computer is mainly used for some drawing, ordering her grocery, and
emailing, she's 80 and she doesn't still really understant what is
internet and how this machine does to send/recieve messages.
The machine is pretty simple, 1 dvd, 1 HD. The USB port is only for the
printer, only one lan card for internet. If the clock can't be off more
than a few seconds a day, there's a problem elsewhere since it looses
around 1 minute per hour.
Did you ear about issues of faulty control over that kind of equipment
with Ubuntu 8.10 ? (TBird900 ... I just can't remember the MB)
root
> * root <NoE...@home.org>:
>> If your drift is so bad that ntpd will not correct, then
>> you have to use adjtimex to set the tick value to bring
>> the clock close enough for ntpd to take over.
>
> Or invoke ntpd with the '-g' option.
>
If the timekeeping is bad enough the -g option doesn't work.
Moe Trin
<hdg9s5$j78$1...@news.albasani.net>, NoE...@home.org wrote:
>Moe Trin <ibup...@painkiller.example.tld> wrote:
>> It's a sanity check, and NTP won't mess with a clock more than a
>> thousand seconds (00:16:40) out of sync, or one that is drifting
>> excessively (500 ppm - man ntpd).
>If your drift is so bad that ntpd will not correct, then
>you have to use adjtimex to set the tick value to bring
>the clock close enough for ntpd to take over.
500 ppm is 43 seconds a day - not outrageous for a cheap wristwatch,
but about five times beyond the manufacturer's limits for the crystal
oscillators used in computers. If you have a steady state drift
of that magnitude, you have b0rken hardware that needs repair or
replacement. The more common problem for an error of that magnitude
is either missed Interrupts, or a motherboard that is using clock
scaling to conserve battery power. Both of these problems are not
steady state, and thus not going to be correctable by adjtimex, or
adjtime. Don't try to hide the symptoms - fix the cause of the
problem instead.
You may want to read the documentation relating to adjtimex. It's
derived from Dr. Mills NTP algorithms.
Old guy
Moe Trin
<hdh97d$2hj1$1...@news.ett.com.ua>, Big Bill wrote:
>Moe Trin a �crit :
>> Either timing source oscillator should be accurate to better than
>> 10 seconds a day. An error of minutes per day LOST usually means
>> interrupt blocking or loss due to bad software, or an over-loaded
>> system with excessive eye-candy.
>Sorry I didn't answer back to anybody but I'm down with the H1N1 and
>I feel like i've been hit by a train and I can't go to that computer
>which is my mother's one.
Agreed - please stay away from the computer AND your mother until you
are feeling better.
>The machine is pretty simple, 1 dvd, 1 HD. The USB port is only for
>the printer, only one lan card for internet. If the clock can't be
>off more than a few seconds a day, there's a problem elsewhere since
>it looses around 1 minute per hour.
A minute per hour is 1:60 or 1.67 percent - that's no hardware error,
but more fits the description of a masked interrupt problem OR the
wrong clock source mentioned by Steve Wampler. Is the software
running on this system all from Debian or Ubuntu sources? I'd expect
that to be better tested and less likely to be causing a masked
interrupt problem, as compared to some of the software available
from other sources.
>Did you ear about issues of faulty control over that kind of equipment
>with Ubuntu 8.10 ? (TBird900 ... I just can't remember the MB)
Looking at the Debian and Ubuntu mailing lists (using a search engine),
I do see the problem being reported as early as Ubuntu 8.04 and
depending on the motherboard, Steve's suggestion of the "clocksource=hpet"
entry in grub.conf may be a solution.
Old guy