[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