[asterisk-dev] possible zaptel problem with SMP and RAID1

Mon Jul 9 08:18:22 CDT 2007

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... :-)) .

François.

Dimitri Prado wrote:
> 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 <fdelawarde at wirelessmundi.com> wrote:
>   
>> Hi again,
>>
>> Tzafrir Cohen wrote:
>>     
>>> Hi
>>>
>>> On Mon, Jul 09, 2007 at 12:29:30PM +0200, François Delawarde wrote:
>>>
>>>       
>>>> 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.
>>>>
>>>>         
>>> What version of Zaptel do you use?
>>>
>>> Is it patched in any way?
>>>
>>> OPVXA1200 uses its own driver, originally based on wctdm.
>>>
>>>       
>> 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.
>>
>>
>>     
>>>> 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?
>>>>
>>>>         
>>> First off, better preemption should generally help you. You need timely
>>> response (be that at the price of some throughput performance).
>>>
>>>       
>> 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?
>>
>>     
>>>> 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
>>>>
>>>>         
>> _______________________________________________
>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>>     
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>   

-- 

 _________________________

François Delawarde

Ingeniero de red

Tel: 918.03.92.51

E-mail: fdelawarde at wirelessmundi.com <mailto:fdelawarde at wirelessmundi.com>

 _________________________

WIRELESS MUNDI

http://www.wirelessmundi.com/

C/Isaac Newton, 1 - Oficina 26 · Parque Tecnológico de Madrid

28760 TRES CANTOS (Madrid)

Tlf./Fax: (+34) 918 03 92 51

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

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.

----------0----------

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.

------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20070709/27dd979e/attachment.htm 