[asterisk-users] How to read IRQs and timing slips values
Shaun Ruffell
sruffell at digium.com
Thu Jan 9 11:30:38 CST 2014
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, 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
More information about the asterisk-users
mailing list