[Asterisk-Users] Interrupt latency problems

[Steven Critchfield]

On Wed, 2004-12-01 at 11:46 -0700, Michael Welter wrote:
> Steven Critchfield wrote:
> 
> > top will only report userspace problems, and to top it off, top only
> > reports on snapshots of the system on as low as 1 second. With Zap
> > hardware hitting the system 1000 times a second for service, you might
> > happen to get an occasional hit time here top and the hardware hit
> > pretty close to show extra load. top also has the problem of effecting
> > the system it is watching. It is a lot like those pesky physics problems
> > where what you use to measure changes the object your measuring.
> > 
> > Basically all that is to say that top probably won't tell you what you
> > want to know.About the only thing that would be of interest is if the
> > percentage is viewed in the system or userspace portions. If in system,
> > you will have to go debugging the kernel. 
> > 
> > Of course, it seems this is mostly being reported against RH and FC.
> > I'll take a quick guess that it isn't bad users so it would leave you
> > with bad kernels. My personal opinion is to not trust what the distros
> > do to the kernels. Even in my beloved Debian I don't trust the default
> > kernel. I suggest you download a stock vanila kernel from kernel.org and
> > config it as minimally as possible for your hardware and try and see if
> > it reproduces the problems you are seeing currently. 
> >
> 
> In line #3 (CPU) of top, I'm seeing idle time go from 100% to +/-30% 
> every 10 seconds.

So again, idle isn't helpfull. Where that time is being spent is the
important part of the details. If it is in system, then it is IO calls
or something else inside the kernel itself. If it is in user, then it is
a userspace app that is getting hit every so often doing damage. 

To give a bit more explicit example, if you have a perl app that wakes
up every 10 seconds or so from a sleep to do some directory managment,
then you would see user percentage spike at that point. However if you
had something dump a large chunk of data to the drives, the kernel would
slurp that data in really quick and then churn on it a moment trying to
get it down to the filesystem. This would show itself as a system time.
If your drive was particularly slow, it very well may hang the interupts
for a moment as it tries to do something.

Old S3 video cards under windows used to be really bad about holding
interupts too long. Used to be if you wiggled the mouse you could hear
the effects in any music you happened to be playing.  
-- 
Steven Critchfield <critch at basesys.com>