[asterisk-users] How to read IRQs and timing slips values
Olivier
oza.4h07 at gmail.com
Tue Jan 14 03:32:01 CST 2014
I had a late phone call yesterday with provider's level-1 support team.
As strange as it seems, the guy said he could "read clock slips in his box
logs though his box is supposed to provide clock and not to use my PBX's
one".
I'm 100% sure my PBX is configured to use provider's clock (but I won't
swear my PBX is currently using provider's clock).
I think I will insert a new Patton box between my provider's one and my PBX
to see what happens.
The setup would be:
PSTN --> provider's equipment <----> Patton GW <----> Asterisk
Then I'll also replace the card inside my PBX to see if things are changing.
2014/1/14 Paul Belanger <paul.belanger at polybeacon.com>
> 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
>
> --
> _____________________________________________________________________
> -- 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/20140114/3afebc8b/attachment.html>
More information about the asterisk-users
mailing list