[OT] Major Clock Drift

[OT] Major Clock Drift

[Josh Myer]

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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Major Clock Drift

[Manfred Bartz]

Josh Myer <jbm@joshisanerd.com> 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>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Major Clock Drift

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

	- Mike

===========================================================================
Michael B. Trausch                                    fd0man@crosswinds.net
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Major Clock Drift

[Steve Underwood]

"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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Major Clock Drift

[Hacksaw]

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/



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Major Clock Drift

[Tom Eastep]

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: tom@seattlefirewall.dyndns.org
ICQ #60745924           \ Websites: http://seawall.sourceforge.net
teastep@evergo.net       \          http://seattlefirewall.dyndns.org
Shoreline, Washington USA \___________________________________________

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Major Clock Drift

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



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Major Clock Drift

[Tom Eastep]

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: tom@seattlefirewall.dyndns.org
ICQ #60745924           \ Websites: http://seawall.sourceforge.net
teastep@evergo.net       \          http://seattlefirewall.dyndns.org
Shoreline, Washington USA \___________________________________________

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Major Clock Drift

[Alan Chandler]

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

alan@chandlerfamily.org.uk
http://www.chandler.u-net.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Major Clock Drift

[Michael B. Trausch]

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                                    fd0man@crosswinds.net
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Major Clock Drift

[Andrew Morton]

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?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Major Clock Drift

[Pavel Machek]

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 pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Major Clock Drift

[Pavel Machek]

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 pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Major Clock Drift

[Pavel Machek]

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 pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Major Clock Drift

[Andrew Morton]

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?

-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Major Clock Drift

[Pavel Machek]

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+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Major Clock Drift

[Andrew Morton]

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.

-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Major Clock Drift

[Peter Horton]

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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Major Clock Drift

[Chris Wedgwood]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Major Clock Drift

[Alan Cox]

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Major Clock Drift

[Andrew Morton]

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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Major Clock Drift

[Alan Cox]

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


	
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Major Clock Drift

[Andi Kleen]

Alan Cox <alan@lxorguk.ukuu.org.uk> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Major Clock Drift

[Alan Cox]

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Major Clock Drift

[Pavel Machek]

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 pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Major Clock Drift

[Alan Cox]

> > 			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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Major Clock Drift

[Andrew Morton]

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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [OT] Major Clock Drift

[James Sutherland]

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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Major Clock Drift

[george anzinger]

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                                    fd0man@crosswinds.net
> 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 majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://vger.kernel.org/lkml/

Re: Major Clock Drift

[Josh Myer]

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.

Re: [OT] Major Clock Drift

[Abramo Bagnara]

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:abramo@alsa-project.org

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!