Well I did say that CPU was not the limiting factor because I tried it on
two CPUs: one much faster than the other but both with the same limit of two
calls.  That's not to say I can't get more calls up - I can get many more
up, but once we get to the third one, there is a degradation in speech
quality for all currently connected (G729) calls.  Even with CPU at only 22%
or so on the slower chip and about 3% IIRC on the faster chip.
 
The CPUs I used are VIA Nehemiah 1 GHz (using
codec_g729-gcc4-uclibc-pentium3.so) and Pentium M 1.7 or 2 GHz GHz (can't
remember which but they are both very fast - using
codec_g729-gcc4-uclibc-pentium-m.so).  And as I said, I tried the same VIA
hardware with AsteriskNOW (using codec_g729-gcc4-pentium3.so) and didn't
have the same audio problem.
 
Are you sure there is no call quality degradation once you get to the third
call?  Which G729 binary are you using?  Which version of AstLinux?  I was
using subversion between 0.4.4 and 0.4.5.
 
Kind regards,
 
Sebastian



  _____  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Michael
Graves
Sent: 25 September 2007 20:31
To: AstLinux Users Mailing List
Subject: Re: [Astlinux-users] Max concurrent G729 calls with uClibc


What you failed to tell us in on what hardware? G729 is very CPU intensive.
I get two calls on a Soekris Net4801 without any trouble. I get four on a HP
T5700 with a 1 GHz Transmeta CPU. Never needed more than 4 so I'm not
certain what the upper limit of the T5700 might be.

Michael

--Original Message Text---
From: Sebastian Auriol
Date: Tue, 25 Sep 2007 13:53:32 +0100

Max concurrent G729 calls with uClibc 

Hi list, 

Has anyone been able to get more than two G729 calls with transcoding of
decent voice quality on AstLinux 0.4 or greater? I was doing some research
into how many calls our hardware was able to transcode from G729 to A-law,
and it seems the limit is two and is not hardware dependent. Once there are
three calls up, the audio on all three calls breaks up. This testing was
done over a LAN, so it shouldn't be a bandwidth problem. CPU on the original
hardware I tested was around 22%, so CPU is not the limiting factor, and I
even tested on much faster hardware (Pentium-M) and the audio still broke up
after the third call. This testing was performed using the open-source G729
uClibc binaries for AstLinux 0.4 as it is for research and I didn't want to
buy licences which would be of no use if it didn't work and of little use
after the research is finished. 

I also tested the open-source glibc G729 binaries with AsteriskNOW on the
same original hardware and I did not have the same problem, so this points
at uClibc as the culprit. 

I talked to the maintainer of these open-source G729 binaries, Arkadi
Shishlov, and he already suspected uClibc, which is why I tested with
AsteriskNOW. 

Here is part of what he said: 
> It is probably uClibc pthread implementation. 
> 6-8 g.729 calls with transcoding in both directions should not be a
problem for this CPU. 

FYI, the original hardware is able to transcode 15 calls from GSM to A-law
fine on AstLinux IIRC. 

I am interested to learn if anyone has been able to get more than two G729
calls up, with either the open-source binary, or the Digium binary. 

Kind regards, 

Sebastian 


P.S. I wrote this e-mail a few months ago, but was going to do a bit more
testing before sending it, but given this apparent flaw with uClibc, and
various other reasons (including possibly more sensibility to jitter than
other distributions), I had to abandon AstLinux (for now at least) and
didn't even have time for more testing. Nevertheless, I thought it might be
interesting to have this discussion in case anyone has anything to
contribute. It would be useful if anyone was able to confirm these problems,
or claim to not have these problems, so I would encourage interested parties
to do their own tests. I would also be interested, of course, in results
from testing the Digium G729 binaries. 

--
Michael Graves                           [EMAIL PROTECTED]
Sr. Product Specialist                          www.pixelpower.com
Pixel Power Inc.                                 [EMAIL PROTECTED]

o713-861-4005
c713-201-1262
skype mjgraves
fwd 54245 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Astlinux-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/astlinux-users

Donations to support AstLinux are graciously accepted via PayPal to [EMAIL 
PROTECTED]

Reply via email to