[asterisk-users] How to read IRQs and timing slips values
Olivier
oza.4h07 at gmail.com
Fri Jan 10 12:48:21 CST 2014
2014/1/9 Shaun Ruffell <sruffell at digium.com>
> On Thu, Jan 09, 2014 at 06:01:34PM +0100, Olivier wrote:
> > Hi,
> >
> > On a Asterisk 1.8.12 system working OK for months (>100k calls proceed),
> > users are complaining for bad audio.
> >
> > My setup is:
> > PSTN <--E1/PRI ---> Asterisk <--- E1/PRI---> Siemens HiPath <---E1/PRI
> > ---> PSTN
> >
> > asterisk -rx "dahdi show version"
> > DAHDI Version: SVN-trunk-r10414 Echo Canceller: HWEC
> >
> > asterisk -rx "pri show version"
> > libpri version: 1.4.12
> >
> >
> >
> > A quick glance at Asterisk logs shows lines like this:
> > [2014-01-09 17:19:34] NOTICE[26034]: chan_dahdi.c:3099
> > my_handle_dchan_exception: PRI got event: HDLC Abort (6) on D-channel of
> > span 1
> > [2014-01-09 17:19:35] NOTICE[26035]: chan_dahdi.c:3099
> > my_handle_dchan_exception: PRI got event: HDLC Abort (6) on D-channel of
> > span 2
> > [2014-01-09 17:19:49] NOTICE[26035]: chan_dahdi.c:3099
> > my_handle_dchan_exception: PRI got event: HDLC Abort (6) on D-channel of
> > span 2
> >
> >
> > I read an old thread inviting an admin to check for shared IRQs and
> timing
> > slips.
> >
> > My questions are:
> >
> > 1. cat /proc/interrupts 's output is:
> > # cat /proc/interrupts
> > CPU0 CPU1 CPU2 CPU3 CPU4 CPU5
> CPU6 CPU7
> > 0: 90147 0 0 0 0 0
> 0 0 IO-APIC-edge timer
> > 1: 2 0 0 0 0 0
> 0 0 IO-APIC-edge i8042
> > 8: 0 0 1 0 0 0
> 0 0 IO-APIC-edge rtc0
> > 9: 0 0 0 0 0 0
> 0 0 IO-APIC-fasteoi acpi
> > 12: 4 0 0 0 0 0
> 0 0 IO-APIC-edge i8042
> > 14: 93 0 0 0 0 0
> 0 0 IO-APIC-edge ata_piix
> > 15: 0 0 0 0 0 0
> 0 0 IO-APIC-edge ata_piix
> > 16: 3378646209 3378695076 3378691115 3378697362 3378691116 3378706831
> 3378710635 3378702358 IO-APIC-fasteoi wct2xxp
> >
> > Can I positively conclude that my Dahdi PRI board IS NOT sharing IRQ
> (which
> > is good) ?
>
> Yes, there is not IRQ sharing going on.
>
> > 2. What would you suggest reading the following output ?
> >
> > cat /proc/dahdi/2
> > Span 2: TE2/0/2 "T2XXP (PCI) Card 0 Span 2" (MASTER) HDB3/CCS
> > Timing slips: 175319
> >
> > 32 TE2/0/2/1 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > 33 TE2/0/2/2 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > 34 TE2/0/2/3 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > 35 TE2/0/2/4 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > 36 TE2/0/2/5 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > 37 TE2/0/2/6 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > 38 TE2/0/2/7 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > 39 TE2/0/2/8 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > 40 TE2/0/2/9 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > 41 TE2/0/2/10 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > 42 TE2/0/2/11 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > 43 TE2/0/2/12 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > 44 TE2/0/2/13 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > 45 TE2/0/2/14 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > 46 TE2/0/2/15 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > 47 TE2/0/2/16 HDLCFCS (In use) (EC: VPMOCT064 - INACTIVE)
> > 48 TE2/0/2/17 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > 49 TE2/0/2/18 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > 50 TE2/0/2/19 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > 51 TE2/0/2/20 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > 52 TE2/0/2/21 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > 53 TE2/0/2/22 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > 54 TE2/0/2/23 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > 55 TE2/0/2/24 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > 56 TE2/0/2/25 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > 57 TE2/0/2/26 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > 58 TE2/0/2/27 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > 59 TE2/0/2/28 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > 60 TE2/0/2/29 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > 61 TE2/0/2/30 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > 62 TE2/0/2/31 Clear (In use) (EC: VPMOCT064 - INACTIVE)
>
> So span 2 has slips, which could explain the HDLC aborts you saw
> previously.
>
> > 3. As shown above, my box has two connections with PSTN (same provider
> for
> > both): one direct, one through an HiPath PBX.
>
> So you've probably nailed it here. It *seems* like the HiPath PBX is
> regenerating the clock on the downstream port based on the other
> information.
>
> > How can I double check timing slips don't come from "inconsistency
> between
> > both clock sources" ?
> >
> > My first thought would be to unplug the link between Asterisk and HiPath
> > and compare two /pro/dahddi/1 outputs.
> > Thoughts ?
>
> Yes, You can monitor the timing slips to see the rate at which they
> occur,
With a single span directly connected to PSTN I'm still getting timing
slips (140 slips/hour).
Would you agree to qualify this rate as excessive ?
Given these figures, may I also exclude an hardware failure inside my card
or on the hosting machine ?
In other words, how to detect a timing slip, Dahdi must use some inner
clock as a reference, doesn't it ? Could this "inner clock" be presently
broken ?
> then connect just one span direct and make sure you don't
> have slips, then one span directly to the HiPath and make sure you
> don't have slips.
>
> If there isn't anyway to configure HiPath to provide the exact same
> clock as the provider to any downstream devices, then you will need
> to use two single port cards in order to sync to two different
> clocks.
>
> Cheers,
> Shaun
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20140110/dcd3a69d/attachment.html>
More information about the asterisk-users
mailing list