Hello all,
I know this _really_ isn't the forum for this, but a friend of mine has
noticed major, persistent clock drift over time. After several weeks, the
clock is several minutes slow (always slow). Any thoughts on the
cause? (Google didn't show up anything worthwhile in the first couple of
pages, so i gave up).
I assume it doens't matter what the mains frequency is (since we're
pulling from a crystal for this anyway). I think i'd heard mention of
problems with other interrupts interrupting the timer often enough that
the time got slowed down, but really?
It's a relatively new Athlon, not sure of the mobo model. If it is a
hardware problem, i'll find out the model, since that would strike me as
an errata =)
Thanks for indulging an idle hardware question
--
/jbm, but you can call me Josh. Really, you can.
Rap-Rock is neither Modern nor Alternative.
Not that I'm bitter.
Josh Myer <[email protected]> writes:
> I know this _really_ isn't the forum for this, but a friend of mine has
> noticed major, persistent clock drift over time. After several weeks, the
> clock is several minutes slow (always slow). Any thoughts on the
> cause? (Google didn't show up anything worthwhile in the first couple of
> pages, so i gave up).
>
> I assume it doens't matter what the mains frequency is (since we're
> pulling from a crystal for this anyway). I think i'd heard mention of
> problems with other interrupts interrupting the timer often enough that
> the time got slowed down, but really?
>
> It's a relatively new Athlon, not sure of the mobo model. If it is a
> hardware problem, i'll find out the model, since that would strike me as
> an errata =)
Try <http://cr.yp.to/clockspeed.html>
On Sat, 3 Feb 2001, Josh Myer wrote:
> Hello all,
>
> I know this _really_ isn't the forum for this, but a friend of mine has
> noticed major, persistent clock drift over time. After several weeks, the
> clock is several minutes slow (always slow). Any thoughts on the
> cause? (Google didn't show up anything worthwhile in the first couple of
> pages, so i gave up).
>
I'm having the same problem here. AMD K6-II, 450 MHz, VIA Chipset, Kernel
2.4.1.
- Mike
===========================================================================
Michael B. Trausch [email protected]
Avid Linux User since April, '96! AIM: ML100Smkr
Contactable via IRC (DALNet) or AIM as ML100Smkr
===========================================================================
"Michael B. Trausch" wrote:
>
> On Sat, 3 Feb 2001, Josh Myer wrote:
>
> > Hello all,
> >
> > I know this _really_ isn't the forum for this, but a friend of mine has
> > noticed major, persistent clock drift over time. After several weeks, the
> > clock is several minutes slow (always slow). Any thoughts on the
> > cause? (Google didn't show up anything worthwhile in the first couple of
> > pages, so i gave up).
> >
>
> I'm having the same problem here. AMD K6-II, 450 MHz, VIA Chipset, Kernel
> 2.4.1.
If you don't use software time correction a minute a week is not too
bad, by current PC standards. Most Compaqs are off by more like a minute
a day. I have verified with a frequency counter that it is actually the
Compaq crystal oscillator which is at fault. Most motherboards are
better than this, but many are not great. The battery backed CMOS clock
is usually a lot better than the interrupt based one, but still not
great. They don't tweak them up like a watch maker would, even though
they usually use the same type of crystal.
Regards,
Steve
Technical explanations aside, some sort of clock drift exists in all
computers. My experience with Sun hardware, for instance, was that the
hardware and software clocks rarely agreed.
You should set up your machines to use some sort of time synchronization
software, such as ntp or rdate. When I didn't have a 24/7 net presence, I had
my ppp script run ntpdate when the connection was complete.
See http://www.eecis.udel.edu/~ntp/
Thus spoke Michael B. Trausch:
> On Sat, 3 Feb 2001, Josh Myer wrote:
>
> > Hello all,
> >
> > I know this _really_ isn't the forum for this, but a friend of mine has
> > noticed major, persistent clock drift over time. After several weeks, the
> > clock is several minutes slow (always slow). Any thoughts on the
> > cause? (Google didn't show up anything worthwhile in the first couple of
> > pages, so i gave up).
> >
>
> I'm having the same problem here. AMD K6-II, 450 MHz, VIA Chipset, Kernel
> 2.4.1.
>
I've discovered that heavy use of vesafb can be a major source of clock
drift on my system, especially if I don't specify "ypan" or "ywrap". On my
system (similar Hw/Sw configuration to yours), a 2.4 kernel "make dep"
from a vesafb console will cause the system clock to drift 10-12 seconds.
With "ywrap", I can do an entire kernel build and only loose 5 seconds or
so. Even with "ywrap", the drift causes ntpd to loose synchronization. If
I build the kernel from an xterm window, ntpd does not loose sync and
there is no apparent clock drift.
The video on this system is an onboard ATI 3D Rage LT Pro; I use vesafb
rather than atyfb because the latter screws up X.
-Tom
--
Tom Eastep \ Alt Email: [email protected]
ICQ #60745924 \ Websites: http://seawall.sourceforge.net
[email protected] \ http://seattlefirewall.dyndns.org
Shoreline, Washington USA \___________________________________________
>I've discovered that heavy use of vesafb can be a major source of clock
>drift on my system, especially if I don't specify "ypan" or "ywrap". On my
This is extremely interesting. What version of ntp are you using?
Thus spoke Hacksaw:
> >I've discovered that heavy use of vesafb can be a major source of clock
> >drift on my system, especially if I don't specify "ypan" or "ywrap". On my
>
> This is extremely interesting. What version of ntp are you using?
>
The RH7 rpm -- ntp-4.0.99k-5
-Tom
--
Tom Eastep \ Alt Email: [email protected]
ICQ #60745924 \ Websites: http://seawall.sourceforge.net
[email protected] \ http://seattlefirewall.dyndns.org
Shoreline, Washington USA \___________________________________________
On Sun, 04 Feb 2001 10:31:35 -0500, you wrote:
>Technical explanations aside, some sort of clock drift exists in all
>computers. My experience with Sun hardware, for instance, was that the
>hardware and software clocks rarely agreed.
>
>You should set up your machines to use some sort of time synchronization
>software, such as ntp or rdate. When I didn't have a 24/7 net presence, I had
>my ppp script run ntpdate when the connection was complete.
>
>See http://www.eecis.udel.edu/~ntp/
>
If you don't have 24/7 net presence then chrony does a nice job of
sorting out your clock.
http://www.rrbcurnow.freeuk.com/freeuk.com/r/r/b/rrbcurnow/webspace/chrony
Alan
[email protected]
http://www.chandler.u-net.com
On Sun, 4 Feb 2001, Tom Eastep wrote:
> Thus spoke Michael B. Trausch:
>
> > On Sat, 3 Feb 2001, Josh Myer wrote:
> >
> > > Hello all,
> > >
> > > I know this _really_ isn't the forum for this, but a friend of mine has
> > > noticed major, persistent clock drift over time. After several weeks, the
> > > clock is several minutes slow (always slow). Any thoughts on the
> > > cause? (Google didn't show up anything worthwhile in the first couple of
> > > pages, so i gave up).
> > >
> >
> > I'm having the same problem here. AMD K6-II, 450 MHz, VIA Chipset, Kernel
> > 2.4.1.
> >
>
>
> The video on this system is an onboard ATI 3D Rage LT Pro; I use vesafb
> rather than atyfb because the latter screws up X.
>
I'm not using any framebuffer on my machine (I have an ATI 3D Rage 128
Pro, myself). I use the standard 80x50 console, and X when I need
it. I'm about to put Debian on the system and see how that works and if I
like it, I just got the .ISO of disc 1 downloaded (after about a week) and
now it's burning. (I hate having a 33.6 connection!)
However the clock drift didn't happen as much, if at all, with 2.2.xx
kernels. It's kept itself pretty well sane. But now I'm losing something
on the order of a half hour a week - that didn't happen before.
- Mike
===========================================================================
Michael B. Trausch [email protected]
Avid Linux User since April, '96! AIM: ML100Smkr
Contactable via IRC (DALNet) or AIM as ML100Smkr
===========================================================================
Hacksaw wrote:
>
> >I've discovered that heavy use of vesafb can be a major source of clock
> >drift on my system, especially if I don't specify "ypan" or "ywrap". On my
>
> This is extremely interesting. What version of ntp are you using?
Is vesafb one of the drivers which blocks interrupts for (many) tens
of milliseconds?
Hi!
> I know this _really_ isn't the forum for this, but a friend of mine has
> noticed major, persistent clock drift over time. After several weeks, the
> clock is several minutes slow (always slow). Any thoughts on the
> cause? (Google didn't show up anything worthwhile in the first couple of
> pages, so i gave up).
Vesafb can do this kind of stuff. Vesafb is evil to interrupt latency,
and at .5sec interrupt latency, clock will loose time.
Pavel
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
Hi!
> > >I've discovered that heavy use of vesafb can be a major source of clock
> > >drift on my system, especially if I don't specify "ypan" or "ywrap". On my
> >
> > This is extremely interesting. What version of ntp are you using?
>
> Is vesafb one of the drivers which blocks interrupts for (many) tens
> of milliseconds?
Vesafb is happy to block interrupts for half a second.
Pavel
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
Hi!
> I've discovered that heavy use of vesafb can be a major source of clock
> drift on my system, especially if I don't specify "ypan" or "ywrap". On my
> system (similar Hw/Sw configuration to yours), a 2.4 kernel "make dep"
> from a vesafb console will cause the system clock to drift 10-12
> seconds.
Hmm, I can make it loose 30 seconds in 12 seconds. Just cat
/etc/termcap. Vesafb does this kind of stuff. [Yes, 3 times slower
clock].
Pavel
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
Pavel Machek wrote:
>
> Hi!
>
> > > >I've discovered that heavy use of vesafb can be a major source of clock
> > > >drift on my system, especially if I don't specify "ypan" or "ywrap". On my
> > >
> > > This is extremely interesting. What version of ntp are you using?
> >
> > Is vesafb one of the drivers which blocks interrupts for (many) tens
> > of milliseconds?
>
> Vesafb is happy to block interrupts for half a second.
And has this been observed to cause clock drift?
-
Hi!
> > > > >I've discovered that heavy use of vesafb can be a major source of clock
> > > > >drift on my system, especially if I don't specify "ypan" or "ywrap". On my
> > > >
> > > > This is extremely interesting. What version of ntp are you using?
> > >
> > > Is vesafb one of the drivers which blocks interrupts for (many) tens
> > > of milliseconds?
> >
> > Vesafb is happy to block interrupts for half a second.
>
> And has this been observed to cause clock drift?
YEs. I've seen time running 3 times slower. Just do cat /etc/termcap
with loaded PCI bus. Yesterday I lost 20 minutes during 2 hours -- I
have been using USB (load PCI) and framebuffer.
Pavel
--
The best software in life is free (not shareware)! Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+
Pavel Machek wrote:
>
> > > Vesafb is happy to block interrupts for half a second.
> >
> > And has this been observed to cause clock drift?
>
> YEs. I've seen time running 3 times slower. Just do cat /etc/termcap
> with loaded PCI bus. Yesterday I lost 20 minutes during 2 hours -- I
> have been using USB (load PCI) and framebuffer.
That's not good. Very not good.
James Simmons has been looking into using something other
than spin_lock_irq(console_lock) to provide the
serialisation which these drivers need. Apparently
it got messy. I'm interested in getting involved
with this problem as well. Sounds like it may not be
2.4 stuff though.
-
On Sun, Feb 11, 2001 at 12:06:14PM +0100, Pavel Machek wrote:
>
> > > > > >I've discovered that heavy use of vesafb can be a major source of clock
> > > > > >drift on my system, especially if I don't specify "ypan" or "ywrap". On my
> > > > >
> > > > > This is extremely interesting. What version of ntp are you using?
> > > >
> > > > Is vesafb one of the drivers which blocks interrupts for (many) tens
> > > > of milliseconds?
> > >
> > > Vesafb is happy to block interrupts for half a second.
> >
> > And has this been observed to cause clock drift?
>
> YEs. I've seen time running 3 times slower. Just do cat /etc/termcap
> with loaded PCI bus. Yesterday I lost 20 minutes during 2 hours -- I
> have been using USB (load PCI) and framebuffer.
> Pavel
Is it not possible to save/check TSC in timer interrupt to correct for
dropped interrupts ? (obviously only on machines that have a TSC ...)
P.
On Sun, Feb 11, 2001 at 10:05:35PM +1100, Andrew Morton wrote:
And has this been observed to cause clock drift?
I've seen clock-tick loss when using matroxfb...
--cw
> Hmm, I can make it loose 30 seconds in 12 seconds. Just cat
> /etc/termcap. Vesafb does this kind of stuff. [Yes, 3 times slower
> clock].
Why are interrupts being disabled for vesafb scrolling anyway ?
Alan Cox wrote:
>
> > Hmm, I can make it loose 30 seconds in 12 seconds. Just cat
> > /etc/termcap. Vesafb does this kind of stuff. [Yes, 3 times slower
> > clock].
>
> Why are interrupts being disabled for vesafb scrolling anyway ?
Console writes happen under spin_lock_irq(console_lock).
The only reason for this which I can see: the kernel
can call printk() from interrupt context.
> > Why are interrupts being disabled for vesafb scrolling anyway ?
>
> Console writes happen under spin_lock_irq(console_lock).
>
> The only reason for this which I can see: the kernel
> can call printk() from interrupt context.
We certainly need to be able to call printk from interrupt context so that
bit is in itself reasonable, but not the cost.
Suppose vesafb did something like this, dropping the printk lock
if(test_and_set_bit(0, &vesafb_lock))
{
if(in_interrupt())
{
// remember which bit of the dmesg ring to queue
queued_writes=1;
return;
}
}
/* for the re-entry case this will block */
down(&vesafb_mutex);
again:
do the usual stuff
if(queued_writes)
{
dequeue_write_buffer();
goto again;
}
up(&vesafb_mutex);
clear_bit(0, &vesafb_lock);
Alan Cox <[email protected]> writes:
> Suppose vesafb did something like this, dropping the printk lock
>
> if(test_and_set_bit(0, &vesafb_lock))
> {
> if(in_interrupt())
> {
> // remember which bit of the dmesg ring to queue
> queued_writes=1;
> return;
Just what happens when you run out of dmesg ring in an interrupt ?
-Andi
> > queued_writes=1;
> > return;
>
> Just what happens when you run out of dmesg ring in an interrupt ?
You lose a couple of lines. Big deal. I'd rather lose two lines a year on
a problem (and the dmesg ring buffer is pretty big) than two minutes an hour
every hour for the entire running life of the machine
Hi!
> > > Why are interrupts being disabled for vesafb scrolling anyway ?
> >
> > Console writes happen under spin_lock_irq(console_lock).
> >
> > The only reason for this which I can see: the kernel
> > can call printk() from interrupt context.
>
> We certainly need to be able to call printk from interrupt context so that
> bit is in itself reasonable, but not the cost.
>
> Suppose vesafb did something like this, dropping the printk lock
>
> if(test_and_set_bit(0, &vesafb_lock))
> {
> if(in_interrupt())
> {
> // remember which bit of the dmesg ring to queue
> queued_writes=1;
> return;
> }
> }
Unfortunately, that means that if machine crashes in interrupt, it may
"loose" printk message. That is considered bad (tm).
Pavel
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
> > queued_writes=1;
> > return;
> > }
> > }
>
> Unfortunately, that means that if machine crashes in interrupt, it may
> "loose" printk message. That is considered bad (tm).
The alternative is that the machine clock slides continually and the machine
is unusable. This is considered even worse by most people
Alan Cox wrote:
>
> > > queued_writes=1;
> > > return;
> > > }
> > > }
> >
> > Unfortunately, that means that if machine crashes in interrupt, it may
> > "loose" printk message. That is considered bad (tm).
>
> The alternative is that the machine clock slides continually and the machine
> is unusable. This is considered even worse by most people
Neither. I was going to dust off my enhanced "bust_spinlocks"
patch which sets a little flag when we're doing an
oops, BUG(), panic() or die(). If the flag
is set, printk() just punches through the lock.
On Mon, 12 Feb 2001, Alan Cox wrote:
> > > queued_writes=1;
> > > return;
> >
> > Just what happens when you run out of dmesg ring in an interrupt ?
>
> You lose a couple of lines. Big deal. I'd rather lose two lines a year on
> a problem (and the dmesg ring buffer is pretty big) than two minutes an hour
> every hour for the entire running life of the machine
Also, you should know when the ring overflows, and be able to indicate
this: it will be clear when and where messages were lost?
James.
I may be off base here, but the problem as described below does _NOT_
seem to be OT so I removed that from the subject line. A clock drift
change with an OS update is saying _something_ about the OS, not the
hardware. In this case it seems to be the 2.4.x OS that is loosing
time. I suspect the cause is some driver that is not being nice to the
hardware, either by abusing the interrupt off code or locking up the bus
or some such. In any case I think it should _not_ be considered OT.
George
"Michael B. Trausch" wrote:
>
> On Sun, 4 Feb 2001, Tom Eastep wrote:
>
> > Thus spoke Michael B. Trausch:
> >
> > > On Sat, 3 Feb 2001, Josh Myer wrote:
> > >
> > > > Hello all,
> > > >
> > > > I know this _really_ isn't the forum for this, but a friend of mine has
> > > > noticed major, persistent clock drift over time. After several weeks, the
> > > > clock is several minutes slow (always slow). Any thoughts on the
> > > > cause? (Google didn't show up anything worthwhile in the first couple of
> > > > pages, so i gave up).
> > > >
> > >
> > > I'm having the same problem here. AMD K6-II, 450 MHz, VIA Chipset, Kernel
> > > 2.4.1.
> > >
> >
> >
> > The video on this system is an onboard ATI 3D Rage LT Pro; I use vesafb
> > rather than atyfb because the latter screws up X.
> >
>
> I'm not using any framebuffer on my machine (I have an ATI 3D Rage 128
> Pro, myself). I use the standard 80x50 console, and X when I need
> it. I'm about to put Debian on the system and see how that works and if I
> like it, I just got the .ISO of disc 1 downloaded (after about a week) and
> now it's burning. (I hate having a 33.6 connection!)
>
> However the clock drift didn't happen as much, if at all, with 2.2.xx
> kernels. It's kept itself pretty well sane. But now I'm losing something
> on the order of a half hour a week - that didn't happen before.
>
> - Mike
>
> ===========================================================================
> Michael B. Trausch [email protected]
> Avid Linux User since April, '96! AIM: ML100Smkr
>
> Contactable via IRC (DALNet) or AIM as ML100Smkr
> ===========================================================================
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
Hello again,
When i originally posted this, it was _highly_ OT. the machine in question
runs windows ME, but i figured the best place to find hardware gurus was
here.
the topic has rather degraded, and while i enjoy getting mail from alan,
the fact that it has nothing to do with me dampens the enthusiasm =)
if you're going to go changing the subject, at least mention framebuffers,
as that seems to be the common thread.
if you all could de-cc me on these, it'd be appreciated.
--
- josh
On Mon, 12 Feb 2001, george anzinger wrote:
> I may be off base here, but the problem as described below does _NOT_
> seem to be OT so I removed that from the subject line. A clock drift
> change with an OS update is saying _something_ about the OS, not the
> hardware. In this case it seems to be the 2.4.x OS that is loosing
> time. I suspect the cause is some driver that is not being nice to the
> hardware, either by abusing the interrupt off code or locking up the bus
> or some such. In any case I think it should _not_ be considered OT.
>
> George
--
/jbm, but you can call me Josh. Really, you can.
Rap-Rock is neither Modern nor Alternative.
Not that I'm bitter.
Andrew Morton wrote:
>
> Alan Cox wrote:
> >
> > > > queued_writes=1;
> > > > return;
> > > > }
> > > > }
> > >
> > > Unfortunately, that means that if machine crashes in interrupt, it may
> > > "loose" printk message. That is considered bad (tm).
> >
> > The alternative is that the machine clock slides continually and the machine
> > is unusable. This is considered even worse by most people
>
> Neither. I was going to dust off my enhanced "bust_spinlocks"
> patch which sets a little flag when we're doing an
> oops, BUG(), panic() or die(). If the flag
> is set, printk() just punches through the lock.
IMO to treat this as an exception it's not the right solution.
A better alternative is to flush one entry of Alan proposed queue on the
following conditions:
- in_interrupt() is true AND queue is full
--
Abramo Bagnara mailto:[email protected]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project is http://www.alsa-project.org
sponsored by SuSE Linux http://www.suse.com
It sounds good!