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) ?
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)
3. As shown above, my box has two connections with PSTN (same provider for
both): one direct, one through an HiPath PBX.
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 ?
Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20140109/a0cc2c08/attachment.html>
Shaun Ruffell
2014-Jan-09 17:30 UTC
[asterisk-users] How to read IRQs and timing slips values
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
Paul Belanger
2014-Jan-14 01:42 UTC
[asterisk-users] How to read IRQs and timing slips values
On Thu, Jan 9, 2014 at 12:01 PM, Olivier <oza.4h07 at gmail.com> 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) ? > > 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) > > 3. As shown above, my box has two connections with PSTN (same provider for > both): one direct, one through an HiPath PBX. > 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 ? > > Regards >I basically had the same issue as you for one of my sites. I tried everything under the sun to figure it out, change cables, loop back test, change out hardware, clocking, etc. In the end I had to upgrade dahdi to 2.7+ and the issue went away. Never did figure out the real problem, but to this day I think the issue was a delay on the frames from the PCI bus into the software. All that to say, try upgrading DAHDI and see what happens. -- Paul Belanger | PolyBeacon, Inc. Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode) Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger