<div dir="ltr"><div><div><div>I could replace the card this morning and the timing slips disappeared.<br><br></div>Given Adrian's testimony, that doesn't mean the card is faulty but as the card is now off service, I'm really eagger to investigate further.<br>
<br></div>At the moment, I can't insert this card and test it again in my lab but I'll certainly do it within a couple of hours (and report here).<br></div>Stay tuned ...<br><br></div><div class="gmail_extra"><br>
<br><div class="gmail_quote">2014/1/14 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 Mon, Jan 13, 2014 at 08:42:13PM -0500, Paul Belanger wrote:<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>
> > 3. As shown above, my box has two connections with PSTN (same provider for<br>
> > both): one direct, one through an HiPath PBX.<br>
> > How can I double check timing slips don't come from "inconsistency between<br>
> > both clock sources" ?<br>
> > My first thought would be to unplug the link between Asterisk and HiPath and<br>
> > compare two /pro/dahddi/1 outputs.<br>
> > Thoughts ?<br>
> ><br>
><br>
</div></div><div class="im">> I basically had the same issue as you for one of my sites. I tried<br>
> everything under the sun to figure it out, change cables, loop back<br>
> test, change out hardware, clocking, etc.<br>
><br>
> In the end I had to upgrade dahdi to 2.7+ and the issue went away.<br>
> Never did figure out the real problem, but to this day I think the<br>
> issue was a delay on the frames from the PCI bus into the software.<br>
><br>
> All that to say, try upgrading DAHDI and see what happens.<br>
<br>
</div>As far as Olivier's concern, I still vote there is some physical<br>
cabling issue that is causing problems.<br>
<br>
However, just for posterity, in my experience if HDLC aborts are<br>
occuring and there are timing slips, it does not have anything to do<br>
with the card / host communication, but rather the issue has more to<br>
do with the framer and connection to provider.<br>
<br>
This is because the timing slips are reported directly by the framer<br>
and that doesn't depend on the host communication.<br>
<br>
Just FYI...<br>
<div class="im HOEnZb"><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>
</div><div class="HOEnZb"><div class="h5">--<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>
</div></div></blockquote></div><br></div>