I would look for some problems somewhere before staring to program
multi-process (which I assume will take some time...) Anyway, maybe
Maxim is interest in making rtpproxy multi-process? I'm not sure what is
to be gained, but I cross-post to serdev.
g-)
Ramu Yadav wrote:
Hi Greg,
Thanks for the reply.
All our calls use G729A codec, and we are running rtpproxy in the Dual
Processor Xeon box.
Apart from the above observation(in my previous mail), rtpproxy is
adding up almost 5-10ms delay when relaying RTP Packets. This is
happening even at a level as low as 20 simultaneous calls.
On 8/28/06, *Greger V. Teigre* <greger(a)teigre.com
<mailto:greger@teigre.com>> wrote:
Are you sure this is due to CPU at 50%?!! AFAIK, rtpproxy can be
run at far higher CPU loads without problems. Have you looked at
your network environment? What's the throughput? Which codec(s) do
you use?
g-)
Ramu Yadav wrote:
Hi All,
With single process RTP Proxy we are facing CPU issues.
When we made around 80 or above odd calls, rtpproxy is taking
CPU(50%), and flow of RTP packets delivering some what late to the UA.
Because of this we are facing some sound quality issues.
To get rid of this CPU usage, we are planning to write rtpproxy as
a multi process.
Is this a good idea to write rtpproxy as multi process or is there
any work around to improve the performance of the rtpproxy.
Help and Ideas are highly appreciated.
--
Ramu Yadav
------------------------------------------------------------------------
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org <mailto:Serusers@lists.iptel.org>
http://lists.iptel.org/mailman/listinfo/serusers
--
Ramu Yadav