roberto.grasso@puntocontatto.it
2005-Jan-04 09:11 UTC
[Asterisk-Users] HDLC Bad FCS (8) HDLC Abort on TE410P
Dear All,
we have installed a TE410P card on a Dell Poweredge 1750 running a slackware
10 with 2.4.26 Kernel. Then we have made two loops on the card and we have
configurated all the 120 channels. Our goals was to perform some stess tests
even if in this scenario we used the same box as generator and target.
The stress test comprised to generate up to 60 calls at the same time by
placing a file in the /var/spool/asterisk/outgoing directory. The call
included even the Play of a demo message.
We did not face any problem up to 30 calls at the same time. Then the following
notices came up:
Jan 4 16:53:37 NOTICE[8621]: PRI got event: HDLC Bad FCS (8) on Primary
D-channel of span 1
Jan 4 16:53:37 NOTICE[8621]: PRI got event: HDLC Abort (6) on Primary D-channel
of span 1
Increasing the traffic up to 50-60 calls at the same time it caused more
serious problems such us the respawn of the channels.
We have also noticed:
cat /proc/zaptel/1
Span 1: TE4/0/1 "TE410P (PCI) Card 0 Span 1" HDB3/CCS/CRC4 ClockSource
IRQ misses: 5
We have tried then to upgrade the box to the kernel 2.6. We have obtained
less mistakes on the HDLC issues and better performance but we had to give
up due to the fact that udevd caused to hug the machine when typing the
modprobe of the card.
Regarding HDLC Abort issues, Have you experienced such a problem? Do you
think is a SW bug? Do you think that is it possible to reduce it by upgrading
the kernel with preemtive patch?
Our zaptel.conf
span=1,1,0,ccs,hdb3,crc4
span=2,0,0,ccs,hdb3,crc4
span=3,0,0,ccs,hdb3,crc4
span=4,0,0,ccs,hdb3,crc4
bchan=1-15, 17-31, 32-46, 48-62, 63-77, 79-93, 94-108, 110-124
dchan=16, 47, 78, 109
loadzone=it
defaultzone=it
zapata.conf
[channels]
;
; GROUP 1
switchtype=EuroISDN
overlapdial=yes
usecallerid=yes
pridialplan=UnKnown
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
rxgain=0.0
txgain=0.0
callgroup=1
pickupgroup=1
immediate=no
;
group = 1
context=in
switchtype=EuroISDN
signalling=pri_cpe
pridialplan=UnKnown
echocancel=yes
channel => 1-15, 17-31, 63-77, 79-93
;
; GROUP 2 -
;
switchtype=EuroISDN
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
rxgain=0.0
txgain=0.0
callgroup=1
pickupgroup=1
immediate=no
;
group = 2
context=out
signalling=pri_net
channel => 32-46, 48-62, 94-108, 110-124
more /proc/interrupts
CPU0 CPU1 CPU2 CPU3
0: 15106973 0 0 0 IO-APIC-edge timer
1: 1534 0 0 0 IO-APIC-edge keyboard
2: 0 0 0 0 XT-PIC cascade
8: 1 0 0 0 IO-APIC-edge rtc
12: 0 0 0 0 IO-APIC-edge PS/2 Mouse
15: 5 0 0 0 IO-APIC-edge ide1
16: 1695332 0 0 0 IO-APIC-level eth0
17: 1510473 0 0 0 IO-APIC-level eth1
18: 129511 0 0 0 IO-APIC-level megaraid
24: 100936929 0 0 0 IO-APIC-level t4xxp
Roberto Grasso
Roberto Grasso
Technical Account Manager
Puntocontatto s.r.l.
Via Alessandrini 9
20016 Pero
tel e fax +39 02 38101310
Cell. 333-5253086
Scott Stingel
2005-Jan-04 09:49 UTC
[Asterisk-Users] HDLC Bad FCS (8) HDLC Abort on TE410P
Hi Roberto- About a year ago, I ran extensive loopback tests of the kind you described. I used various processors and motherboards, and used Fedora Core 1 with 2.4 kernels. (See the asterisk-users message archives and the wiki for more info). I got similar results to yours, except that I had no "IRQ misses". I think that the underlying problem is that the processor is not quite keeping up with the interrupt service. My customer likes HP's, so I ran it on a couple models and found that I had to move up to the Proliant DL360 (3.4 Ghz Dual Xeon) before I could get absolutely trouble-free operation with all 120 channels running. At the time, the theory seemed to be that a lot of call setup's, not just overall call load, contributed to the problem, and that asterisk's recovery from frame errors was less than ideal and introduced a bunch of overhead. Anyway, I gave up looking for perfection and just use a very fast processor when I want to handle 120 channels with no errors. Best regards Scott Stingel President Emerging Voice Technology, Inc. www.evtmedia.com ------------------------------------------- roberto.grasso@puntocontatto.it wrote:>Dear All, > >we have installed a TE410P card on a Dell Poweredge 1750 running a slackware >10 with 2.4.26 Kernel. Then we have made two loops on the card and we have >configurated all the 120 channels. Our goals was to perform some stess tests >even if in this scenario we used the same box as generator and target. >The stress test comprised to generate up to 60 calls at the same time by >placing a file in the /var/spool/asterisk/outgoing directory. The call >included even the Play of a demo message. >We did not face any problem up to 30 calls at the same time. Then the following >notices came up: >Jan 4 16:53:37 NOTICE[8621]: PRI got event: HDLC Bad FCS (8) on Primary >D-channel of span 1 >Jan 4 16:53:37 NOTICE[8621]: PRI got event: HDLC Abort (6) on Primary D-channel >of span 1 >Increasing the traffic up to 50-60 calls at the same time it caused more >serious problems such us the respawn of the channels. > >We have also noticed: > > cat /proc/zaptel/1 >Span 1: TE4/0/1 "TE410P (PCI) Card 0 Span 1" HDB3/CCS/CRC4 ClockSource > IRQ misses: 5 > > >We have tried then to upgrade the box to the kernel 2.6. We have obtained >less mistakes on the HDLC issues and better performance but we had to give >up due to the fact that udevd caused to hug the machine when typing the >modprobe of the card. >Regarding HDLC Abort issues, Have you experienced such a problem? Do you >think is a SW bug? Do you think that is it possible to reduce it by upgrading >the kernel with preemtive patch? > >Our zaptel.conf > >span=1,1,0,ccs,hdb3,crc4 >span=2,0,0,ccs,hdb3,crc4 >span=3,0,0,ccs,hdb3,crc4 >span=4,0,0,ccs,hdb3,crc4 >bchan=1-15, 17-31, 32-46, 48-62, 63-77, 79-93, 94-108, 110-124 >dchan=16, 47, 78, 109 >loadzone=it >defaultzone=it > >zapata.conf > >[channels] >; >; GROUP 1 >switchtype=EuroISDN >overlapdial=yes >usecallerid=yes >pridialplan=UnKnown >hidecallerid=no >callwaiting=yes >usecallingpres=yes >callwaitingcallerid=yes >threewaycalling=yes >transfer=yes >cancallforward=yes >callreturn=yes >echocancel=yes >echocancelwhenbridged=yes >rxgain=0.0 >txgain=0.0 >callgroup=1 >pickupgroup=1 >immediate=no >; >group = 1 >context=in >switchtype=EuroISDN >signalling=pri_cpe >pridialplan=UnKnown >echocancel=yes >channel => 1-15, 17-31, 63-77, 79-93 >; >; GROUP 2 - >; >switchtype=EuroISDN >usecallerid=yes >hidecallerid=no >callwaiting=yes >usecallingpres=yes >callwaitingcallerid=yes >threewaycalling=yes >transfer=yes >cancallforward=yes >callreturn=yes >echocancel=yes >echocancelwhenbridged=yes >rxgain=0.0 >txgain=0.0 >callgroup=1 >pickupgroup=1 >immediate=no >; >group = 2 >context=out >signalling=pri_net >channel => 32-46, 48-62, 94-108, 110-124 > > > > > more /proc/interrupts > CPU0 CPU1 CPU2 CPU3 > 0: 15106973 0 0 0 IO-APIC-edge timer > 1: 1534 0 0 0 IO-APIC-edge keyboard > 2: 0 0 0 0 XT-PIC cascade > 8: 1 0 0 0 IO-APIC-edge rtc > 12: 0 0 0 0 IO-APIC-edge PS/2 Mouse > 15: 5 0 0 0 IO-APIC-edge ide1 > 16: 1695332 0 0 0 IO-APIC-level eth0 > 17: 1510473 0 0 0 IO-APIC-level eth1 > 18: 129511 0 0 0 IO-APIC-level megaraid > 24: 100936929 0 0 0 IO-APIC-level t4xxp > > >Roberto Grasso > >Roberto Grasso > >Technical Account Manager >Puntocontatto s.r.l. >Via Alessandrini 9 >20016 Pero >tel e fax +39 02 38101310 >Cell. 333-5253086 > >_______________________________________________ >Asterisk-Users mailing list >Asterisk-Users@lists.digium.com >http://lists.digium.com/mailman/listinfo/asterisk-users >To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > >. > > >