[asterisk-users] Issues with dahdi show status output (and check IRQs)

[Shaun Ruffell]

On Fri, Dec 09, 2011 at 05:11:47PM +0100, Olivier wrote:
> 2011/12/8, Shaun Ruffell <sruffell at digium.com>:
> > On Thu, Dec 08, 2011 at 06:41:46PM +0100, Olivier wrote:

> >> 2. On a more general plan, is taking down layer 1 on idling spans
> >> something PBXs are negociating with each other (the public switch
> >> trying to take the layer one down, listening to an acknowledge
> >> from the private PBX) or is it more brutal than that ?
> >
> > Not that I'm aware of, but I could be mistaken.
> 
> Is it correct to think that Point-to-Point BRI is not (or less) prone
> to this phenomenon ?
> 
> My (poor and un-recommended) knowledge of Point-to-Point BRI mode is
> that it mimics PRI in that a single D-channel concentrates signalling
> for several BRI lines.

I've personally only seen this on a P-to-P link where the telephony
provider starts idling a span to save power. I do not have much
experience with Point-to-Multipoint so I'm not sure if it's even
possible there.

> For compleness sake, is there somewhere a check list we can read to be
> sure we are not hit by these "drivers (disk in PIO, framebuffers,
> serial consoles on slow links) taking too much time in interrupt
> context".

Not that I'm aware of.

However, the typically symptom of one of these drivers are regular
messages in your kernel log from the driver about "latency" bumps.

The latency bumps are caused when some system condition prevents the
driver from servicing it's interrupt quickly enough. Certain
frame buffer drivers hold of interrupts to scroll your video console,
or a disk driver has interrupts locked while doing (slow) programmed
IO (PIO) to the disk controller, etc.. To compensate, the driver
adds extra latency (currently at 1ms increments) in order to give it
more time in the future (at the cost of a 1ms extra delay in the
audio path) to service the interrupts. But some systems have so much
latency that they aren't well suited for the soft real-time
constraints of telephony.

-- 
Shaun Ruffell
Digium, Inc. | Linux Kernel Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com & www.asterisk.org