16 thoughts on - How To Read IRQs And Timing Slips Values

• Yes, there is not IRQ sharing going on.

  So span 2 has slips, which could explain the HDLC aborts you saw previously.

  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.

  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

• 2014/1/9 Shaun Ruffell

  With a single span directly connected to PSTN I’m still getting timing slips (140 slips/hour). Would you agree to qualify this rate as excessive ?

  Given these figures, may I also exclude an hardware failure inside my card or on the hosting machine ?
  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 ?

• Yes, this is excessive.

  You’ve configured the card to recover timing from the provider? If so, do your slips follow the actual cable that you were using to connect to provider or PBX?

• 2014/1/10 Shaun Ruffell

  I’m not sure but I don’t think so as I’ve just configured the card with:

  span=1,1,0,ccs,hdb3
  bchan=1-15,17-31
  dchan
  echocanceller=oslec,1-15,17-31

  span=2,2,0,ccs,hdb3
  bchan2-46,48-62
  dchanG
  echocanceller=oslec,32-46,48-62

  Span1 is the one direct to provider equipement. Span2 is thh one that was connected to HiPath and which is simply unplugged

• That looks correct. You might want to check your cables next. Do you only get timing slips when connected to the provider, or to the HiPath as well?

• 2014/1/10 Shaun Ruffell

  For a couple of days now, I’m only connected to the provider. Just in case, I commented out in system.conf and dahdi-channels.conf, any reference to “the HiPath span” and ran a “dahdi restart now”:
  unfortunately, I’m still observing timing slips at a rate of 1220
  slips/hour.

  I have a spare TE4xx board. Shall I replace current TE2xx with this spare and see if things improve or would you advise an other check ?

  Regards

• If you have another board, yes, you could try. But I would recommend checking all your cables, etc. Also, while highly unlikely, I’ve heard of cases in the past where some smaller providers were expecting to source timing from customer premise PBX (since they were acting as a SIP gateway on the backend).

  Your provider does expect you to source their clock?

• Check the T1 cable doesn’t pass any high EMI area’s like a power supply.

  Adrian

• Ask your carrier to test the circuit. Often HDLC errors, especially with modern cards, are caused by a dirty T-1 not a PBX or card issue.

  —–Original Message—

• 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.

• 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

• I have had to power the server down, UNPLUG the power, leave unplugged for 4 minutes, power up. I had a T1 timing issue this procedure fixed.

  Adrian

• As far as Olivier’s concern, I still vote there is some physical cabling issue that is causing problems.

  However, just for posterity, in my experience if HDLC aborts are occuring and there are timing slips, it does not have anything to do with the card / host communication, but rather the issue has more to do with the framer and connection to provider.

  This is because the timing slips are reported directly by the framer and that doesn’t depend on the host communication.

  Just FYI…

• I could replace the card this morning and the timing slips disappeared.

  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.

  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). Stay tuned …

  2014/1/14 Shaun Ruffell

• Follow up on this thread:

  Today, I could at last insert the TE220 board into an other machine in my lab.

  1. For the moment, I plugged the card into an available PCIe x1 slot and checked IRQs with:

  # dmesg
  …
  [ 42.969568] dahdi: Version: SVN-trunk-r10414
  [ 43.281832] wct4xxp 0000:04:08.0: PCI INT A -> GSI 17 (level, low) ->
  IRQ 17
  [ 43.281855] wct4xxp 0000:04:08.0: 5th gen card with initial latency of 2
  and 1 ms per IRQ
  [ 43.281861] wct4xxp 0000:04:08.0: Firmware Version: c01a016d
  [ 43.284411] wct4xxp 0000:04:08.0: FALC Framer Version: 3.1
  [ 43.284420] IRQ 17/wct2xxp: IRQF_DISABLED is not guaranteed on shared IRQs
  [ 43.284465] wct4xxp 0000:04:08.0: Found a Wildcard: Wildcard TE220 (5th Gen)
  [ 43.306504] wct4xxp 0000:04:08.0: firmware: requesting dahdi-fw-oct6114-064.bin
  [ 43.568475] VPM450: echo cancellation for 64 channels
  [ 48.722467] wct4xxp 0000:04:08.0: VPM450: hardware DTMF disabled.
  [ 48.722471] wct4xxp 0000:04:08.0: VPM450: Present and operational servicing 2 span(s)
  [ 50.304512] wct4xxp 0000:04:08.0: TE2XXP: Span 1 configured for CCS/HDB3
  [ 50.304543] wct4xxp 0000:04:08.0: RCLK source set to span 1
  [ 50.304547] wct4xxp 0000:04:08.0: Recovered timing mode, RCLK set to span 1
  [ 50.304615] wct4xxp 0000:04:08.0: SPAN 1: Primary Sync Source

  # cat /proc/interrupts
  CPU0 CPU1
  0: 46 24 IO-APIC-edge timer
  1: 0 2 IO-APIC-edge i8042
  7: 1 0 IO-APIC-edge parport0
  8: 0 1 IO-APIC-edge rtc0
  9: 0 0 IO-APIC-fasteoi acpi
  12: 0 6 IO-APIC-edge i8042
  14: 0 0 IO-APIC-edge pata_atiixp
  15: 0 0 IO-APIC-edge pata_atiixp
  16: 1 339 IO-APIC-fasteoi xhci_hcd:usb3, ohci_hcd:usb4, ohci_hcd:usb5, HDA Intel
  17: 2216 7235841 IO-APIC-fasteoi ehci_hcd:usb1, wct2xxp
  …

  Does it qualify as “incompatible with Dahdi because of shared IRQ” or can I
  get along and keep testing on this machine ?

  2. I plugged a straight patch cord into one E1 port and the other cord’s plug into the small socket provided with card.
  (I’m referring here to a female RJ45 socket mounted on a 1cm x 2cm PCB)

  The port light turns green and dahdi_tool says status is OK.

  At the same time, I’m seeing timing slips as with:
  # cat /proc/dahdi/1
  Span 1: TE2/0/1 “T2XXP (PCI) Card 0 Span 1” (MASTER) HDB3/CCS ClockSource
  Timing slips: 75

  The rate is 3 slips/minute. Has this figure any meaning (I don’t have any other card to compare with) ?

  3. When I’m plugging the same E1 port into a Smartnode E1 gateway port
  (then using an E1 crossover cable), dahdi_tool tells status is OK
  but asterisk logs are full of lines such as (~ 20 occurences per second)):
  [2014-02-03 13:46:04] NOTICE[2076]: chan_dahdi.c:3099
  my_handle_dchan_exception: PRI got event: HDLC Abort (6) on D-channel of span 1

  Sometimes, a line like the one bellow slides between the above ones.
  [2014-02-03 13:50:24] NOTICE[2076]: chan_dahdi.c:3099
  my_handle_dchan_exception: PRI got event: HDLC Bad FCS (8) on D-channel of span 1

  Thoughts ?

  2014-01-15 Olivier :

• I would suggest updating DAHDI. We moved from svn to git years ago and that repository is not maintained.

  This is fine. I would only worry about sharing irqs with hardware that would compete for interrupt time, like a network controller or disk controller.

  3 slips a minute is too high. You’ll likely hear audio artifacts like clicks or pops if you were listening to audio on the line. This may give you a bit more info on acceptable slip rates. http://www.youtube.com/watch?v=2UNfzEuv1uk#t78

  HDLC aborts are a symptom of timing slips, typically.

  If you’re legitimately recovering timing from the network properly, then I would look at what the upstream provider is doing. Your provider should be able to run long term loop/pattern tests to your smartjack to determine link quality issues.