Author |
|
jmatthewsr Junior
Joined: April 09 2008 Posts: 40
|
Posted: May 22 2008 at 11:49am | IP Logged
|
|
|
Is the following typical for conferencing? On the SUT (system under test) the max conference participants is 40.
All tests run on Pentium D 2.8Ghz 3GB RAM Windows Server 2008. All calls are g.711mulaw.
With 32 people in conference (3 conferences with 10 users, 1 with 2 users):
CPU: 30%
Working Set: 170MB
With 40 people in conference(3 conferences, 10 users per conference):
CPU: 80%
Working Set: 350MB
33 People in conference (11 conferences with 3 people in each conference)
CPU: 37%
Working Set: 365MB
|
Back to Top |
|
|
support Administrator
Joined: January 26 2005 Location: United States Posts: 1666
|
Posted: May 22 2008 at 4:12pm | IP Logged
|
|
|
Hi Justin,
I hate to be stupid, but I’m not quite sure what you are asking. The “numbers are the numbers”. Whatever you get depends on your host hardware. I know, it’s a lame answer. :)
The first 2 conference scenarios you described are so closely related… they should have just about the same CPU utilization. I have to think….
Conferencing many into a single session can get costly relative to CPU requirements (it’s a factorial situation). We have on our engineering “to do” list an internal change that will help to bring down CPU demands when conferencing many users into a single conference call group. We just have to get around to implementing it. If you can, maybe rephrase your question with an additional follow-up post.
BTW: When are you going to make your purchase? :)
Thanks,
Support
|
Back to Top |
|
|
jmatthewsr Junior
Joined: April 09 2008 Posts: 40
|
Posted: May 22 2008 at 4:45pm | IP Logged
|
|
|
My question is if these numbers are in line with what you have experienced on your own test systems. If the numbers I gave are considerably off from what you would expect then I would think that I have the system misconfigured or there are some other settings that are hurting performance. These performance numbers are not as good as I had hoped. The jump in CPU from 30 to 40 total participants (not everyone is in a single conference) does not show a linear increase.
We are getting closer to purchasing, but we have to continue bulk call testing the software. The performance numbers may affect the number of licenses required. We also have an outstanding deadlock (or similar) problem that is still outstanding.
-justin
|
Back to Top |
|
|
support Administrator
Joined: January 26 2005 Location: United States Posts: 1666
|
Posted: May 23 2008 at 7:31am | IP Logged
|
|
|
Hi Justin,
Good response. We understand now what you are asking.
System misconfigured or settings that are hurting performance:
Using the media engine with conferencing support is straight forward. Its either enabled for use or disabled via startup parameter values. So there is no chance that performance is a config issue. Once conference support is enabled, your app initiates or receives calls. Once the calls are in the “in-call state (i.e. SipInCall state), you can call the SetConferenceGroupIds() API proc to specify a conference session ID for the call. Then call the ConferenceLine() API proc to place the phone line into or out of conference mode. That’s it. No other operations or configuration have to be done. If this is what you are doing, then your app is using the media engine correctly.
Notes about call media:
Using all uLaw or aLaw call media will reduce the overall CPU load when conferencing is active. Using G729 or iLBC call media will increase CPU load. As we stated in a previous post, we have an engineering change that will be implemented that will reduce conferencing CPU loading by “quite a bit”. What is “quite a bit”? We do not have the hard numbers yet but it should be substantial. Just put it this way: We will be updating the way conference media streams are being handled to optimize the number of format/rate conversion that have to be done between phone lines. When completed, this will allow us all to squeeze more conference call capability out of the same CPU(s).
Regarding the other deadlock issue:
Don’t let this stop you from making a purchase. If you purchase, you get the latest code. The issue may already be fixed. If it is not fixed, rest assured it will get resolved.
Support
|
Back to Top |
|
|