From: Michael Frank <mhf@linuxmail.org>
To: Bill Anderson <banderson@hp.com>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: system (not HW) clock advancing really fast
Date: Mon, 16 Feb 2004 16:41:33 +0800 [thread overview]
Message-ID: <200402161641.33323.mhf@linuxmail.org> (raw)
In-Reply-To: <1076917697.25980.35.camel@perseus>
On Monday 16 February 2004 15:48, Bill Anderson wrote:
> On Mon, 2004-02-16 at 00:45, Michael Frank wrote:
> > On Monday 16 February 2004 15:26, Bill Anderson wrote:
> > > On Sun, 2004-02-15 at 23:24, Michael Frank wrote:
> > > > I had this somtetimes when using ntpd doing step time update
> > > > resulting in silly values in /etc/adjtime .
> > > >
> > > > # mv /etc/adjtime /tmp
> > > > # hwclock --systohc
> > > >
> > > > and see if it goes away.
> > >
> > > Thanks, though it didn't work. :(
> > >
> >
> > Please check your /etc/ntp/drift , the value in it is
> > usually between -30.0 and 30.0
> >
> > If it is much larger than that, set it to 0.0 and restart ntpd.
>
>
> Done that, too. in fact, that was my first target.
> Along with stop ntpd, sync, clear drift, clear adjtime, sync again, and
> restart ntpd. Sorry, should have said that. It's been a *looong* time
> since I've posted here.
The basic suggestions were bound to be redundant ;)
>
> I just tried some new stuff that is interesting.
>
> MachineA is the one with the problem. MachineB is an identical machine
> (as far as two machines can be).
>
> On MachineA I am seeing some interesting things with /proc/interrupts
> and the timer interrupt line.
>
> On MachineA:
> Over 10 seconds (wall clock):
> CPU0: 107 interrupts/second (avg)
> CPU1: 102.5 interrupts/second (avg)
> [Over 10K interrupts difference between the two]
> On MachineB:
> Over 10 seconds (wall clock):
> CPU0: 46.4 interrupts/second (avg)
> CPU1: 45.5 interrupts/second (avg)
> [Over 10K interrupts difference between the two]
>
> Now, the CPU differences don't make me blink. However, the slightly more
> than double the rate of timer interrupts on the problem machine is
> interesting to me. or is it a red herring/blind alley? Especially since
> it now seems to be ~2 seconds per second fast.
>
When running vmstat, on 2.4 100+ idle interrupts/s is normal,
100 for the clock, and a few extra for what else goes on.
If the machines are _identical_, your problem points definitely
to hardware.
a) Timer broken - too fast.
b) Generates IRQ's on both edges
c) the clock interrupt being routed into both CPU's
at the same time.
You could boot with NOSMP to rule out c)
Weird breakdown anyway,
Regards
Michael
next prev parent reply other threads:[~2004-02-16 8:32 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-16 5:46 system (not HW) clock advancing really fast Bill Anderson
2004-02-16 6:24 ` Michael Frank
2004-02-16 7:26 ` Bill Anderson
2004-02-16 7:45 ` Michael Frank
2004-02-16 7:48 ` Bill Anderson
2004-02-16 8:41 ` Michael Frank [this message]
2004-02-16 8:50 ` Michael Frank
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200402161641.33323.mhf@linuxmail.org \
--to=mhf@linuxmail.org \
--cc=banderson@hp.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox