vicidial.org

Hello there,
I've a spare Sangoma A102 (Dual E1/T1) and I'm wondering if is it ok for using as hardware timing source.
We use only VoIP lines and we haven't pri lines right now. Has it to be connected to a pri line to do its work?

I'm trying this after using a X100P and Dahdi_Dummy, for both the audio is very very very poor

It's a very good timing source. Though if you ask me it's kinda expensive to be used as one. Why not just get a Sangoma USB timing device? By the way, the A102 doesn't need to be connected to a PRI line to work as a timer. Just make sure dahdi_dummy or ztdummy is not loaded too.

Ok, thank you. I've asked this because I've an average of 98% with Sangoma and 99,98% with dahdi_dummy

There was a recent fix in Sangoma Driver and/or Firmware. From what I understand from the changelog, before this fix the Sangoma Drivers did not work so well as a timing source unless they were connected to an external source. A problem which caused high cpu utilization in the interrupt service routine was also solved, so I really recommend you to upgrade to the last available versión of the driver and firmware.

I recommend you to just check the changelogs for more information.

Thank you very much! I've upgraded to 3.5.10 but I still have got very poor timing, average 98.3 %...

These are my confs, hope anyone can help me!

Code: Select all

 cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3
  0:         63          1          0          0   IO-APIC-edge      timer
  1:          2          2          3          3   IO-APIC-edge      i8042
  8:          0          0          1          0   IO-APIC-edge      rtc0
  9:          0          0          0          0   IO-APIC-fasteoi   acpi
 16:        865        865       7842       7426   IO-APIC-fasteoi   3w-sas
 17:      25212        806        732        810   IO-APIC-fasteoi   wanpipe1
 19:        123         39         38         39   IO-APIC-fasteoi   ata_piix, ata_piix
217:       2040         77         76         77   PCI-MSI-edge      eth1
218:         15         24         13         73   PCI-MSI-edge      eth0
NMI:          0          0          0          0   Non-maskable interrupts
LOC:      30827      26603      25560     242571   Local timer interrupts
RES:        829        757        820        874   Rescheduling interrupts
CAL:        244        244        233        125   function call interrupts
TLB:       1781       2655       1752       2331   TLB shootdowns
TRM:          0          0          0          0   Thermal event interrupts
SPU:          0          0          0          0   Spurious interrupts
ERR:          0
MIS:          0


Code: Select all

init.conf
#
# Shell settings for Dahdi initialization scripts.
# This replaces the old/per-platform files (/etc/sysconfig/zaptel,
# /etc/defaults/zaptel)
#

# The maximal timeout (seconds) to wait for udevd to finish generating
# device nodes after the modules have loaded and before running dahdi_cfg.
#DAHDI_DEV_TIMEOUT=40

# Override settings for xpp_fxloader
#XPP_FIRMWARE_DIR=/usr/share/dahdi
#XPP_HOTPLUG_DISABLED=yes


system.conf
loadzone=it
defaultzone=it

#Sangoma A102 port 1 [slot:1 bus:6 span:1] <wanpipe1>
span=1,1,0,ccs,hdb3,crc4
bchan=1-15,17-31
echocanceller=mg2,1-15,17-31
hardhdlc=16

chan_dahdi.conf
;autogenerated by /usr/sbin/wancfg_dahdi do not hand edit
;autogenrated on 2010-03-04
;Dahdi Channels Configurations
;For detailed Dahdi options, view /etc/asterisk/chan_dahdi.conf.bak

[trunkgroups]

[channels]
context=default
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
relaxdtmf=yes
rxgain=0.0
txgain=0.0
group=1
callgroup=1
pickupgroup=1
immediate=no

;Sangoma A102 port 1 [slot:1 bus:6 span:1] <wanpipe1>
switchtype=euroisdn
context=from-pstn
group=0
echocancel=yes
signalling=pri_cpe
channel =>1-15,17-31


wanpipe1.conf
#================================================
#
# Date: Wed Dec  6 20:29:03 UTC 2006
#
# Note: This file was generated automatically
#       by /usr/local/sbin/setup-sangoma program.
#
#       If you want to edit this file, it is
#       recommended that you use wancfg program
#       to do so.
#================================================
# Sangoma Technologies Inc.
#================================================

[devices]
wanpipe1 = WAN_AFT_TE1, Comment

[interfaces]
w1g1 = wanpipe1, , TDM_VOICE, Comment

[wanpipe1]
CARD_TYPE       = AFT
S514CPU         = A
CommPort        = PRI
AUTO_PCISLOT    = NO
PCISLOT         = 1
PCIBUS          = 6
FE_MEDIA        = E1
FE_LCODE        = HDB3
FE_FRAME        = CRC4
FE_LINE         = 1
TE_CLOCK        = NORMAL
TE_REF_CLOCK    = 0
TE_SIG_MODE     = CCS
TE_HIGHIMPEDANCE        = NO
TE_RX_SLEVEL    = 430
LBO             = 120OH
FE_TXTRISTATE   = NO
MTU             = 1500
UDPPORT         = 9000
TTL             = 255
IGNORE_FRONT_END = NO
TDMV_SPAN       = 1
TDMV_DCHAN      = 16
TDMV_HW_DTMF    = NO
TDMV_HW_FAX_DETECT = NO

[w1g1]
ACTIVE_CH       = ALL
TDMV_HWEC       = NO
MTU             = 8


I don't know if correct, but I've found a little trick to use HPET

In kernel config,CONFIG_HIGH_RES_TIMERS needs to be enabled (Processor type and features -> High Resolution Timer Support), and optionally, (Processor type and features -> HPET Timer Support)

Add "clocksource=hpet" to menu.lst
Recompile Dahdi

the finalt result should be:

Code: Select all

dmesg | grep dahdi
dahdi: Telephony Interface Registered on major 196
dahdi: Version: 2.2.0.2
dahdi_dummy: Trying to load High Resolution Timer
dahdi_dummy: Initialized High Resolution Timer
dahdi_dummy: Starting High Resolution Timer
dahdi_dummy: High Resolution Timer started, good to go
dahdi: Registered tone zone 0 (United States / North America)

Code: Select all

cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm jiffies

Code: Select all

cat /sys/devices/system/clocksource/clocksource0/current_clocksource
hpet

They says that kernel has to be > 28, but I can't understand why.

Obviously my dahdi_test continues to be very poor

Code: Select all

--- Results after 515 passes ---
Best: 100.000 -- Worst: 99.994 -- Average: 99.997800, Difference: 99.997808


Do you experience any other issues?
The last results don't seem that bad at all, on some machines you simply won't get any better ones, and this does create issues.

okli wrote:Do you experience any other issues?
The last results don't seem that bad at all, on some machines you simply won't get any better ones, and this does create issues.

Thank you for answering. The bad thing is that is the only issue, Vicidial goes like a charme, the agents are falling in love with it, but they can't really make a call, because of delays, too low volume, etc. The strange thing is that the quality is perfect if they make calls directly from the phones (Express Talk and X-Lite) through the vicidial PBX. So I think the problem is in the meetme conferences. But I'm really stuck in this problem

Have you tried contacting Sangoma support, they really do have very knowledgeable support staff that may be able to help you with this.

What Linux distro are you using?

gardo wrote:What Linux distro are you using?

ì'm using Vicibox Redux, opensuse 11.1

Can you check the following kernel settings?

CONFIG_HZ_100
CONFIG_PREEMPT_NONE
CONFIG_HPET

# uname -r (to get your kernel version.)

To get the kernel settings above:

# grep CONFIG_HZ_100 /boot/config-`uname -r`
# grep CONFIG_PREEMPT_NONE /boot/config-`uname -r`

gardo wrote:Can you check the following kernel settings?

CONFIG_HZ_100
CONFIG_PREEMPT_NONE
CONFIG_HPET

# uname -r (to get your kernel version.)

To get the kernel settings above:

# grep CONFIG_HZ_100 /boot/config-`uname -r`
# grep CONFIG_PREEMPT_NONE /boot/config-`uname -r`

Thank you for answering gardo, in the meanwhile I've downgraded to 1.4.21 with zaptel, tomorrow I'll test this solution.

for you questions:

Code: Select all

vicidialDBWEB:/etc/init.d # uname -r
2.6.27.42-0.1-default

vicidialDBWEB:/etc/init.d # grep CONFIG_HZ_100 /boot/config-`uname -r`
# CONFIG_HZ_100 is not set
# CONFIG_HZ_1000 is not set

vicidialDBWEB:/etc/init.d # grep CONFIG_PREEMPT_NONE /boot/config-`uname -r`
CONFIG_PREEMPT_NONE=y


There was an issue with earlier Sangoma 3.4 drivers where if you did not have a loop establish the timing on the card would drop to 96-98 percent. The fix was to establish a loop with either a loop-back plug or a T1 crossover from one port to the other.

They have supposively fixed this and a few bugs related to it in v.3.4.7 and higher. The version of wanpipe included with ViciBox Redux (OpenSuSE ViciBox) is v.3.4.6. I will package a new version with the latest release (v.3.4.9) in a little while.

In the meantime, you can try upgrading your driver and card firmware to the latest stable sangoma release and it should fix your problem.

Kumba wrote:There was an issue with earlier Sangoma 3.4 drivers where if you did not have a loop establish the timing on the card would drop to 96-98 percent. The fix was to establish a loop with either a loop-back plug or a T1 crossover from one port to the other.

They have supposively fixed this and a few bugs related to it in v.3.4.7 and higher. The version of wanpipe included with ViciBox Redux (OpenSuSE ViciBox) is v.3.4.6. I will package a new version with the latest release (v.3.4.9) in a little while.

In the meantime, you can try upgrading your driver and card firmware to the latest stable sangoma release and it should fix your problem.

My test was with 3.4.9 and then 3.5.10. Same 98,3 % Tomorrow I'll try with a loop!

PS: I see that I can update firmware too. Tomorrow I'll check the firmware, hopely!