[asterisk-users] Asterisk choking on voice messages announcements

[Steve Murphy]

On Wed, Apr 21, 2010 at 6:13 PM, bruce bruce <bruceb444 at gmail.com> wrote:

> How can I find out what the source of the problem is guys?
>
> As I said I didn't change anything, except for making few minor changes to
> the firewall today and that was at Amazon firewall level and not within
> CentOS.
>
> What causes these bad dahdi_test values?
>
> P.S. there is only few calls load at anytime on this server.
>

Here are few ideas:

1. I have seen complaints that as Amazon loads up its virtual machines, that
neighboring VM's running on the same hardware are sucking up CPU cycles and
reducing the performance of the other VM's on board. One guy was complaining
that to get the same performance he got a few months ago, he has to move to
a more powerful machine, which costs more $$$$. You might move up to a more
expensive, faster VM and see if it helps.

2. I don't know exactly how Dahdi gets its timing, but I do know that it has
two methods; one involves HIGH RES TIMERS compiled into the kernel. The
other when the high-res stuff isn't included. You can decompress
/proc/config.gz into a local file and look for HIGHRES to be defined. If it
isn't you might try to find a kernel with it defined, and see if it helps.

3. If you are on 1.6.1 or 1.6.2 (too tired to look up which), you could try
using another method of generating timing than dahdi_dummy. I suspect that
they may just reflect code already in Dahdi_dummy... but this seems like
something you might want to become knowledgeable about!

murf




> Thanks
>
> On Wed, Apr 21, 2010 at 8:03 PM, Carlos Chavez <cursor at telecomabmex.com>wrote:
>
>> On Wed, 2010-04-21 at 19:36 -0400, bruce bruce wrote:
>> > Here are result of dahdi_test:
>> >
>> >
>> > [root at ip-10-251-123-3 ~]# dahdi_test
>> > Opened pseudo dahdi interface, measuring accuracy...
>> > 99.725% 96.018% 99.532% 91.934% 99.923% 99.923% 99.628% 99.434%
>> > -434.763% 99.239% 93.770% 99.141% 99.822% 91.232% 99.727% 93.770%
>> > 99.726% -403.227% 98.069% 98.458% 95.136% 98.749% 91.229% 87.622%
>> > 98.554% 93.282% -407.620% 94.650% 96.308% 98.750% 96.993% 93.478%
>> > 94.063% 93.381% 61.745% -379.400% 99.628% 99.921% 99.142% 96.797%
>> > 98.457% 99.337% 87.909% 95.141% -396.880% 99.531% 99.923% 99.921%
>> > 91.035% 96.408% 91.916% 90.255% -402.153% 81.079% 74.534% 96.212%
>> >
>> >
>> > What can one tell from these?
>> >
>>         Only that your timing source sucks.  You need 99.9% or higher if
>> you
>> want a stable system.  I have servers with dahdi_dummy that never go
>> below 99.7% accuracy.  You really need to check your timing source.
>>
>> --
>> Telecomunicaciones Abiertas de México S.A. de C.V.
>> Carlos Chávez Prats
>> Director de Tecnología
>> +52-55-91169161 ext 2001
>>
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>> New to Asterisk? Join us for a live introductory webinar every Thurs:
>>               http://www.asterisk.org/hello
>>
>> asterisk-users mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-users
>>
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>               http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>



-- 
Steve Murphy
ParseTree Corp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20100421/99f977d2/attachment.htm