On Fri, Dec 09, 2011 at 05:11:47PM +0100, Olivier wrote: > 2011/12/8, Shaun Ruffell <sruff...@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 -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users