[comp.unix.ultrix] Frequent interrupts under Ultrix 4.0

cks@hawkwind.utcs.toronto.edu (Chris Siebenmann) (08/15/90)

 The colour DECStation 5000 I just upgraded to Ultrix 4.0 is now
getting about 280 interrupts a second even when it's totally idle.
Quite frankly, I'd like the 10% of the CPU that they're eating up
back. Unfortunately I have no idea what is causing them; they happen
even when I boot the machine single-user.

 Has anyone else seen this behavior? Has anyone managed to work out
why it happens and/or how to stop it?

 Thanks in advance.

[*Sigh. New OS versions. I won't even mention how the multiuser boot
 sequence seems to start out on Wed Dec 31 19:00:02 EST 1969 about
 half the time.]
--
		 "You don't *run* programs on Ultrix." - Mark Moraes
		 "Right, you chase them." - Rayan Zachariassen
cks@hawkwind.utcs.toronto.edu	           ...!{utgpu,utzoo,watmath}!utgpu!cks

mogul@wrl.dec.com (Jeffrey Mogul) (08/16/90)

In article <1990Aug15.024310.8785@jarvis.csri.toronto.edu> cks@hawkwind.utcs.toronto.edu (Chris Siebenmann) writes:
> The colour DECStation 5000 I just upgraded to Ultrix 4.0 is now
>getting about 280 interrupts a second even when it's totally idle.
>Quite frankly, I'd like the 10% of the CPU that they're eating up
>back. Unfortunately I have no idea what is causing them; they happen
>even when I boot the machine single-user.
>
> Has anyone else seen this behavior? Has anyone managed to work out
>why it happens and/or how to stop it?

DECstations run with HZ = 256; i.e., the clock interrupt happens
256 times a second.  The other 24 interrupts per second (or so)
are probably related to I/O (such as file system "sync" activity,
Ethernet broadcasts, etc.).

It appears as if the way that vmstat and the kernel collaborate to
decide how many interrupts/second are happening changed between
3.1D and 4.0, for MIPS (but not for Vax) systems.  I.e., there's
some code in vmstat.c to subtract HZ from the interrupt count
for the Vax but not for the MIPS, and I suspect that someone changed
the MIPS kernel to act like the Vax kernel but didn't change vmstat.c.
Since the manual page for vmstat says "in" means "non clock" interrupts,
I suppose this is a bug ... in vmstat, not the kernel.

I seriously doubt that the clock interrupts are eating 10% of the
CPU; not only does my DS5000 show about 98%-99% idle time (in
"vmstat") but I've hacked my DS3100 (a slower machine) to run with
HZ = 4096.  It shows about 4120 interrupts/sec and also shows 98%-99%
idle.  So, I don't think the clock-interrupt handling consumes that
much of the CPU.  (I suppose "vmstat" might not be reporting the
idle time accurately; how did you arrive at the 10% figure?)

It is possible that your "extra" 24 interrupts/sec (which is about
what I see, too) are caused by things that require your CPU to do
something nasty (if each "wasted" 4 mSec, the total would be about
10% of the CPU).

-Jeff