<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014/1/9 Shaun Ruffell <span dir="ltr"><<a href="mailto:sruffell@digium.com" target="_blank">sruffell@digium.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Thu, Jan 09, 2014 at 06:01:34PM +0100, Olivier wrote:<br>
> Hi,<br>
><br>
> On a Asterisk 1.8.12 system working OK for months (>100k calls proceed),<br>
> users are complaining for bad audio.<br>
><br>
> My setup is:<br>
> PSTN <--E1/PRI ---> Asterisk <--- E1/PRI---> Siemens HiPath <---E1/PRI<br>
> ---> PSTN<br>
><br>
> asterisk -rx "dahdi show version"<br>
> DAHDI Version: SVN-trunk-r10414 Echo Canceller: HWEC<br>
><br>
> asterisk -rx "pri show version"<br>
> libpri version: 1.4.12<br>
><br>
><br>
><br>
> A quick glance at Asterisk logs shows lines like this:<br>
> [2014-01-09 17:19:34] NOTICE[26034]: chan_dahdi.c:3099<br>
> my_handle_dchan_exception: PRI got event: HDLC Abort (6) on D-channel of<br>
> span 1<br>
> [2014-01-09 17:19:35] NOTICE[26035]: chan_dahdi.c:3099<br>
> my_handle_dchan_exception: PRI got event: HDLC Abort (6) on D-channel of<br>
> span 2<br>
> [2014-01-09 17:19:49] NOTICE[26035]: chan_dahdi.c:3099<br>
> my_handle_dchan_exception: PRI got event: HDLC Abort (6) on D-channel of<br>
> span 2<br>
><br>
><br>
> I read an old thread inviting an admin to check for shared IRQs and timing<br>
> slips.<br>
><br>
> My questions are:<br>
><br>
> 1. cat /proc/interrupts 's output is:<br>
> # cat /proc/interrupts<br>
> CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7<br>
> 0: 90147 0 0 0 0 0 0 0 IO-APIC-edge timer<br>
> 1: 2 0 0 0 0 0 0 0 IO-APIC-edge i8042<br>
> 8: 0 0 1 0 0 0 0 0 IO-APIC-edge rtc0<br>
> 9: 0 0 0 0 0 0 0 0 IO-APIC-fasteoi acpi<br>
> 12: 4 0 0 0 0 0 0 0 IO-APIC-edge i8042<br>
> 14: 93 0 0 0 0 0 0 0 IO-APIC-edge ata_piix<br>
> 15: 0 0 0 0 0 0 0 0 IO-APIC-edge ata_piix<br>
> 16: 3378646209 3378695076 3378691115 3378697362 3378691116 3378706831 3378710635 3378702358 IO-APIC-fasteoi wct2xxp<br>
><br>
> Can I positively conclude that my Dahdi PRI board IS NOT sharing IRQ (which<br>
> is good) ?<br>
<br>
</div></div>Yes, there is not IRQ sharing going on.<br>
<div><div class="h5"><br>
> 2. What would you suggest reading the following output ?<br>
><br>
> cat /proc/dahdi/2<br>
> Span 2: TE2/0/2 "T2XXP (PCI) Card 0 Span 2" (MASTER) HDB3/CCS<br>
> Timing slips: 175319<br>
><br>
> 32 TE2/0/2/1 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> 33 TE2/0/2/2 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> 34 TE2/0/2/3 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> 35 TE2/0/2/4 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> 36 TE2/0/2/5 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> 37 TE2/0/2/6 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> 38 TE2/0/2/7 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> 39 TE2/0/2/8 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> 40 TE2/0/2/9 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> 41 TE2/0/2/10 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> 42 TE2/0/2/11 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> 43 TE2/0/2/12 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> 44 TE2/0/2/13 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> 45 TE2/0/2/14 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> 46 TE2/0/2/15 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> 47 TE2/0/2/16 HDLCFCS (In use) (EC: VPMOCT064 - INACTIVE)<br>
> 48 TE2/0/2/17 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> 49 TE2/0/2/18 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> 50 TE2/0/2/19 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> 51 TE2/0/2/20 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> 52 TE2/0/2/21 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> 53 TE2/0/2/22 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> 54 TE2/0/2/23 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> 55 TE2/0/2/24 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> 56 TE2/0/2/25 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> 57 TE2/0/2/26 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> 58 TE2/0/2/27 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> 59 TE2/0/2/28 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> 60 TE2/0/2/29 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> 61 TE2/0/2/30 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> 62 TE2/0/2/31 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
<br>
</div></div>So span 2 has slips, which could explain the HDLC aborts you saw<br>
previously.<br>
<div class="im"><br>
> 3. As shown above, my box has two connections with PSTN (same provider for<br>
> both): one direct, one through an HiPath PBX.<br>
<br>
</div>So you've probably nailed it here. It *seems* like the HiPath PBX is<br>
regenerating the clock on the downstream port based on the other<br>
information.<br>
<div class="im"><br>
> How can I double check timing slips don't come from "inconsistency between<br>
> both clock sources" ?<br>
><br>
> My first thought would be to unplug the link between Asterisk and HiPath<br>
> and compare two /pro/dahddi/1 outputs.<br>
> Thoughts ?<br>
<br>
</div>Yes, You can monitor the timing slips to see the rate at which they<br>
occur,</blockquote><div><br></div><div>With a single span directly connected to PSTN I'm still getting timing slips (140 slips/hour).<br></div><div>Would you agree to qualify this rate as excessive ?<br></div><div><br>
</div><div>Given these figures, may I also exclude an hardware failure inside my card or on the hosting machine ?<br></div><div>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 ?<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> then connect just one span direct and make sure you don't<br>
have slips, then one span directly to the HiPath and make sure you<br>
don't have slips.<br>
<br>
If there isn't anyway to configure HiPath to provide the exact same<br>
clock as the provider to any downstream devices, then you will need<br>
to use two single port cards in order to sync to two different<br>
clocks.<br>
<br>
Cheers,<br>
Shaun<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Shaun Ruffell<br>
Digium, Inc. | Linux Kernel Developer<br>
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>
Check us out at: <a href="http://www.digium.com" target="_blank">www.digium.com</a> & <a href="http://www.asterisk.org" target="_blank">www.asterisk.org</a><br>
<br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
New to Asterisk? Join us for a live introductory webinar every Thurs:<br>
<a href="http://www.asterisk.org/hello" target="_blank">http://www.asterisk.org/hello</a><br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-users" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>
</font></span></blockquote></div><br></div></div>