<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Actually, we plan on using an external echo canceller, but testing with
or without Octasis gave the same results. We didn't try HPEC, and
reverting to ECHO_CAN_KB1 gives the same result (yes i have tried lots
of things... :-)) .<br>
<br>
François.<br>
<br>
<br>
Dimitri Prado wrote:
<blockquote
cite="midcc9969300707090553p3b7b5392j859e1185e8f7accd@mail.gmail.com"
type="cite">
<pre wrap="">Hello,
this is probably not related, but we had tons of interrupt problems
when we used zaptel compiled with ECHO_CAN_MG2. When we reverted to
ECHO_CAN_KB1 everything worked fine again. Both setups had no IDE,
framebuffer, shared irqs etc.
regards
Dimitri
On 7/9/07, François Delawarde <a class="moz-txt-link-rfc2396E" href="mailto:fdelawarde@wirelessmundi.com"><fdelawarde@wirelessmundi.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi again,
Tzafrir Cohen wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi
On Mon, Jul 09, 2007 at 12:29:30PM +0200, François Delawarde wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hello,
I thought this mail would be more appropriate in this mailing list, if
not sorry about it.
I've been having interrupt problems since I'm trying to use analog
zaptel hardware (mainly openvox A400 and OPVXA1200) on two dual core
machines (AMD64 X2, different motherboards and network cards) with
software RAID1 in two SATA drives. These problems didn't occur on my
previous setups without any RAID.
</pre>
</blockquote>
<pre wrap="">What version of Zaptel do you use?
Is it patched in any way?
OPVXA1200 uses its own driver, originally based on wctdm.
</pre>
</blockquote>
<pre wrap="">Zaptel 1.4.3 with 1 line hookstate patch from bug 0008290 (adapted from
1.2.10 to 1.4.3)
I also tried non-patched Zaptels from 1.2 and 1.4 series.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">The problem appears to happen randomly, a few times per minute (or
sometimes per 5 minutes), zttest utility drops to 60-90%, saying that I
had too many interrupts (showing lines like "8192 samples in 7212 sample
interval"). Along with that come an audible "bip" and some rare times a
small cut in conversation, or a small bit of echo during a very short
time. I'll add that a higher disk load (running dbench) appears to
increase a little the frequence of those problems (but not totally sure).
zttool show no missed interrupts with watchdog option enable before
compilation. No shared interrupts. No IDE drives (related to possible
DMA problem). No frame buffer, console only server. Tried with all
PREEMPT kernel options, all HZ options, with and without IRQ balance,
trying SMP afinity to switch interrupts to another core, all without
result, except for PREEMPT options that makes zttest constantly report
99.975586% instead of 100% when there are no problems.
I'm no kernel expert, but since the only pattern I found in all tests
seemed to be related to RAID, I was wondering if spinlocks disabling
interrupts like RAID drivers seem to be doing in SMP configuration would
be the cause of delaying of zaptel interrupts, leading to the kind of
problems I have. Any idea on that?
</pre>
</blockquote>
<pre wrap="">First off, better preemption should generally help you. You need timely
response (be that at the price of some throughput performance).
</pre>
</blockquote>
<pre wrap="">That's what I originally thought and thus tried those options to see if
it could resolve my problem. Right now, running on 2.6.21.6 with "Low
latency Desktop", and HZ=1000, without success.
Any idea?
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">For info, the problem occurred on these combinations of setups:
- OS: Debian etch (tested on sarge)
- Processors: two different AMD64 X2, one of each is in AM2 socket.
- Partitions: ext3 on RAID1 (tested with ext3 on LVM on RAID1 and ext3
on Encrypted LVM on RAID1)
- Custom kernel 2.6.21.6 with IMQ and Layer 7 (tested with 2.6.18 and
with/without these two patches, also tested with XEN kernel with
horrible, but expected results).
- zaptel 1.4.3 (tried 1.2 series, and 1.4 since 1.4.1).
- a few services: DNS, DHCP, Samba, PHP/MySQL interface, astmanproxy
(tested without any).
Worked well on:
- OS: Debian etch
- AMD64 Sempron
- Kernel 2.6.18 with IMQ and Layer 7
- No RAID
- zaptel 1.4 series
- same services as above
</pre>
</blockquote>
</blockquote>
<pre wrap="">_______________________________________________
--Bandwidth and Colocation Provided by <a class="moz-txt-link-freetext" href="http://www.api-digital.com">http://www.api-digital.com</a>--
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
<a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a>
</pre>
</blockquote>
<pre wrap=""><!---->
_______________________________________________
--Bandwidth and Colocation Provided by <a class="moz-txt-link-freetext" href="http://www.api-digital.com">http://www.api-digital.com</a>--
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
<a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a>
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<style>
/* Style Definitions */
p.line
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman";
        color:blue;}
p.name
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Times New Roman";
        color:black;
        font-weight:bold;}
p.title
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:8.0pt;
        font-family:"Times New Roman";
        color:blue;
        font-weight:bold;}
p.contact
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:8.0pt;
        font-family:"Times New Roman";
        color:blue;}
p.logo
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman";
        color:#DC352A;
        font-weight:bold;}
p.disclaimer
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:7.5pt;
        font-family:"Times New Roman";
        color:#454545;}
a:link
        {color:blue;
        text-decoration:underline;}
a:visited
        {color:purple;
        text-decoration:underline;}
</style>
<p class="line"> _________________________</p>
<p class="name">François Delawarde</p>
<p class="title">Ingeniero de red</p>
<p class="contact">Tel: 918.03.92.51</p>
<p class="contact">E-mail: <a
href="mailto:fdelawarde@wirelessmundi.com">fdelawarde@wirelessmundi.com</a></p>
<p class="line"> _________________________</p>
<p class="logo">WIRELESS MUNDI</p>
<p class="contact"><a href="http://www.wirelessmundi.com/">http://www.wirelessmundi.com/</a></p>
<p class="contact">C/Isaac Newton, 1 - Oficina 26 · Parque Tecnológico
de Madrid</p>
<p class="contact">28760 TRES CANTOS (Madrid)</p>
<p class="contact">Tlf./Fax: (+34) 918 03 92 51</p>
<hr size="2" width="100%">
<p class="disclaimer">La información contenida en este mensaje y en sus
archivos adjuntos es CONFIDENCIAL y se dirige exclusivamente a sus
destinatarios. Queda expresamente prohibida la utilización de la misma
por cualquier persona distinta de los destinatarios de esta
comunicación. Si usted ha recibido este mensaje por error le rogamos
que lo comunique inmediatamente a WIRELESS MUNDI y lo borre al igual
que todos sus documentos adjuntos. El correo electrónico no puede
asegurar la confidencialidad ni la integridad de sus mensajes por lo
que WIRELESS MUNDI no se hace responsable de tales errores u omisiones.</p>
<p class="disclaimer" align="center"><font color="#454545"
face="Verdana" size="1">----------0----------</font></p>
<p class="disclaimer"><font color="#454545" face="Verdana" size="1">All
information in this message and its attachments is confidential and may
be legally privileged. Only intended recipients are authorized to use
it. If you have received this transmission in error, please notify
WIRELESS MUNDI immediately and delete this message and its attachments.
E-mail transmissions are not guaranteed to be secure or error free and
WIRELESS MUNDI does not accept liability for such errors or omissions.</font></p>
<hr size="2" width="100%">
</div>
</body>
</html>