Tracy R Reed wrote:
Some of you may recall that I have been working on building a box to
convert H323 to SIP. After a significant amount of outside help and
slicing and dicing of the ohh323 code to get it to compile on AMD64 we
finally got it working. Now we are working on improving the performance.
Do you want to share the details of the installation?
I would like to make things easier for the installation of
asterisk-oh323 by fixing the stuff that made your day (days?)
harder.
This box takes H323 from one device and converts to SIP and spits it back
out to another device. The codec is g729 but we do not have any g729
licenses on the box because we are doing pass-through so I figure the cpu
usage should not be a problem and some sort of bandwidth issue would be
hit first.
Hardware stats:
AMD Athlon(tm) 64 Processor 3000+
512M of RAM
100Mb/s full duplex switched ethernet
Linux bit64.foo.com 2.6.9-1.667 #1 Tue Nov 2 14:50:10 EST 2004 x86_64 x86_64
x86_64 GNU/Linux
Software:
Asterisk CVS-HEAD-11/26/04-12:38:01 built by [EMAIL PROTECTED] on a x86_64
running Linux
asterisk-oh323-0.7.0
The problem: If we point 24 voice channels of traffic at the box we see 5%
cpu utilization and all is well. But cpu utilization scales non-linearly
until we have 96 voice channels and 50% cpu utilization. At this rate we
won't scale to nearly where we had hoped to. According to the
voip-info.org wiki a g729 stream is usually around 30kb/s including
overhead etc so 96 channels would be 2.8Mb/s. Since we have that coming in
and out total bandwidth is 5.6Mb/s. Not much at all I wouldn't think. At a
20ms sample rate 96 channels is 4800 packets per second times two for
incoming and outgoing and we get 9600 packets per second. Again, not that
much. About 25% of the cpu seems to go to the asterisk process and 25% to
the system. Absolutely no swapping is going on. At 24 channels the load
average barely ticks above zero. At 96 it hits around 8. I don't know if
it matters but there is no zaptel hardware at all in this box, pure voip.
Anyone have any idea where the bottleneck could be or any tuning tweaks we
could make?
For a start perform the same test but doing "SIP to SIP" and not
"H323 to SIP" and check the cpu utilization for the same figures
of calls and call rate. Don't forger to disable reinvites on these
calls, in order to be the test comparable to the "H323 to SIP"
scenario.
With both results we will get a clue about the portion of the
utilization of the system for each protocol (SIP/H323) and
the part that needs to be optimized. For sure the greatest
part will be of H323 but how much of it is it?
Michael.
_______________________________________________
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
