[Home]

Summary:ASTERISK-05170: Hardware HDLC in Zaptel
Reporter:Matthew Fredrickson (mattf)Labels:
Date Opened:2005-09-27 21:54:54Date Closed:2008-06-07 11:18:00
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk-hardhdlc.diff
( 1) hardhdlc-ss7.diff
( 2) zaptel-hardhdlc.diff
( 3) zaptel-hardhdlc3.diff
Description:This patch will enable the quad and dual span Digium cards to do HDLC in hardware.  You will need to apply the patch to zaptel (it's against head) and the patch against chan_zap.c.  To enable, simply replace in /etc/zaptel.conf your dchan= line to hardhdlc= line.

****** ADDITIONAL INFORMATION ******

Please include which style of card you are using for this (1st gen or 2nd gen).
Comments:By: Michael Jerris (mikej) 2005-09-27 22:07:23

What is the benefit of an option for this?  If it is supported on the card, why would you ever not want to use it transparently?
By: Matthew Fredrickson (mattf) 2005-09-27 22:41:14

Oh my goodness... just try it out.  Right now it is an option.  Maybe it will be automatic in the future.  One reason is that this MIGHT tie up more system time than doing it in software, though there are advantages to using this interface that make it somewhat more appealing.  Doing it in hardware, there are larger buffers, so it is not quite as unforgiving on a crappy setup where you have missed interrupts, etc.  It's also somewhat of an experimental (i.e. new) feature, so I don't want it to default to doing it in hardware at the moment.  Also, it would make it difficult to do back to back conformance testing against the software implementation if it automatically did that.  Must I go on? :-)
By: Paul Cadach (pcadach) 2005-09-29 13:48:31

Very nice work Matthew! Thanks a lot! It is the feature I asked Mark for about 1-1,5 years ago thinking about possibility to simplify HDLC/LAPD/SS7 processing after reading reports on openss7.org and by Steve Underwood.

Presently CPU is more-or-less cheap but processing speed is still limited by different buses, slow (in comparsion with CPU speed) RAM, etc. So usage of hardware when it possible is very helpful anyway. The SS7 projects (openss7 and SteveU's one) is real acknoweledge to this concept.
By: adomjan (adomjan) 2005-09-29 18:40:01

Nice! I'm testing on a 1st gen TE410.
By: Andrew Kohlsmith (akohlsmith) 2005-10-02 18:56:00

I've started testing on a TE406P and 1st gen TE405P.
By: Matthew Fredrickson (mattf) 2005-10-03 14:51:38

I just uploaded a new version.  It has a bug fix so that you can change from soft to hard hdlc by just running ztcfg (without a module reload).
By: Andrew Kohlsmith (akohlsmith) 2005-10-03 14:55:03

is that a bug fix then or just a feature?  So far it's been working great here on the TE406 (didn't get it on the TE405rev1 yet).
By: Matthew Fredrickson (mattf) 2005-10-03 15:00:58

Well, I guess that depends on what you define as a bug :-)  It should function the same, but if you got tired of reloading the module every time you wanted to switch between hard and soft hdlc, you can do it with just ztcfg now.
By: adomjan (adomjan) 2005-10-03 15:11:04

I tried the new patch, the zap had not worked. I switch back to soft hdlc, zaptel worked, and I tried to switch back to hardware hdlc -> the machine crashed.
By: Matthew Fredrickson (mattf) 2005-10-03 15:16:39

Ok, I'll have to look at it some more.  I'll just pull that one down until I can test it better then.
By: Paul Cadach (pcadach) 2005-10-03 22:56:27

To make ztcfg works there is needs to add one line at zt_ctl_ioctl() function for case ZT_CHANCONFIG (marked with ">>>"):
...
               if (!res) {
                       chans[ch.chan]->sig = ch.sigtype;
>>>                        chans[ch.chan]->flags &= ~ZT_FLAG_NOSTDTXRX;
                       if (chans[ch.chan]->sig == ZT_SIG_CAS)
                               chans[ch.chan]->idlebits = ch.idlebits;
                       else
                               chans[ch.chan]->idlebits = 0;
                       if ((ch.sigtype & ZT_SIG_CLEAR) == ZT_SIG_CLEAR) {
...
Sorry, I'm not ready to generate diff file just because studying another problem with softhdlc<->hardhdlc communication.
By: cmaj (cmaj) 2005-10-14 11:45:55

Using GCC 4, I had to move the body of __t4_framer_interrupt to get it to compile.
By: Matthew Fredrickson (mattf) 2005-11-22 14:28:58.000-0600

Here is a new version that includes updates that I made for doing some MTP2 related off loading.
(for SS7)


By: Martin Vit (festr) 2005-12-02 11:24:12.000-0600

i'm trying latest (2.12.2005) cvs-head with hardhdlc-ss7.diff.
i've Wildcard TE410P/TE405P (1st Gen)

/etc/zaptel.conf
span=1,0,0,ccs,hdb3,crc4
bchan=1-15,17-31
#dchan=16
hardhdlc=16

ztcfg -vvv:
...
Channel 16: Hardware assisted D-channel (Default) (Slaves: 16)
...

asterisk -vvvgcd:
everything is ok, but d-channel does not start

------cut-------
Dec  2 19:12:04 NOTICE[5538]: chan_zap.c:6310 handle_init_event: Alarm cleared on channel 14
Dec  2 19:12:04 DEBUG[5534]: chan_zap.c:8182 pri_dchannel: Got event No more alarm (5) on D-channel for span 1
Dec  2 19:12:04 DEBUG[5538]: chan_zap.c:6607 do_monitor: Monitor doohicky got event No more alarm on channel 15
Dec  2 19:12:04 NOTICE[5538]: chan_zap.c:6310 handle_init_event: Alarm cleared on channel 15
------cut-------

*CLI> pri show span 1
1  2  3  4
*CLI> pri show span 1
Primary D-channel: 16
Status: Provisioned, Down, Active
------cut-------

If I change hardhdlc=16 to dchan=16

ztccfg -vvvv:
...
Changing signalling on channel 16 from Unknown to HDLC with FCS check
...

and D-channel get up and everything is ok. If i change dchan=16 to hardhdlc=16 again:

ztcfg -vvvv:
...
Changing signalling on channel 16 from HDLC with FCS check to Unknown
....

and D-channel is still up. If run ztcfg -vvv for the second time, D-channel is down.

where could be problem? I'm very interesting with HDLC in hardware, because on one overloaded system (50 concurent calls (g729), dual XEON 2.8, there is problem with rejected frames and D-channel crashesh (cpu up to 60%) (kernel 2.6.11-686-smp debian preempt off, irqbalance)
By: Matthew Fredrickson (mattf) 2005-12-02 13:00:58.000-0600

For the SS7 version of the patch, you'll have to change a variable in wct4xxp.c

You'll need to change the sigmode in the beginning from FRMR_MODE_SS7 to FRMR_MODE_NO_ADDR_CMP
By: Martin Vit (festr) 2005-12-02 15:30:40.000-0600

thanks for quick answer! after this change, it works now. But if i insmod wct4xxp and run ztcfg twice, D-channel want get up, until rmmod/insmod and run ztcfg only once.

Anyone here have done some perfomrmance tests with and without hw hdlc?
By: Matthew Fredrickson (mattf) 2006-01-10 15:09:50.000-0600

Applied to trunk
By: Digium Subversion (svnbot) 2008-06-07 11:17:50

Repository: dahdi
Revision: 887

U   trunk/zaptel.c
U   trunk/zaptel.h
U   trunk/ztcfg.c

------------------------------------------------------------------------
r887 | mattf | 2008-06-07 11:17:48 -0500 (Sat, 07 Jun 2008) | 3 lines

Commits for HardHDLC API in zaptel (ASTERISK-5170)


------------------------------------------------------------------------

http://svn.digium.com/view/dahdi?view=rev&revision=887
By: Digium Subversion (svnbot) 2008-06-07 11:18:00

Repository: dahdi
Revision: 888

U   trunk/wct4xxp.c

------------------------------------------------------------------------
r888 | mattf | 2008-06-07 11:17:58 -0500 (Sat, 07 Jun 2008) | 2 lines

Add experimental support for Hardware HDLC for D-channels (ASTERISK-5170)

------------------------------------------------------------------------

http://svn.digium.com/view/dahdi?view=rev&revision=888