Home
Performance of 16E1s SS7 Sangoma SMG PDF Print E-mail
User Rating: / 14
PoorBest 
Written by Paweł Pierścionek   
Wednesday, 02 April 2008 00:00

Performance tests of 16E1s SS7 Sangoma Media Gateway

 

Sponsored by:

Required Level: novice, accomplished, adept, master

 

Abstract:

In this article we present performance data on 16E1 SS7 setup based on Sangoma's SMG & Asterisk as a voice application server.
CPU usage and Unix system load are analysed as a function of number of calls in the answered state both for centralized & distributed setup. Load analysis shows that in a distributed setup a Dual Core 3GHz AMD Opteron server has enough resources to handle full 16E1 load with room for additional applications like SIP termination.

Goals:

Test CPU usage in two scenarios of SMG deployment :

  • centralized - SMG & Asterisk on the same server (eg simple SS7 gateway)
  • distributed - one SMG many Asterisks on separated servers (eg transcoding & prepaid SIP2PSTN cluster)
The Goal is to measure performance of SMG components without any specific application. No SIP or media transcoding overhead are included in proposed tests.

Lab Setup :

Fig. 1 - Different SMG setups interconnected

 

Sangoma SMG Introducion:

Sangoma SMG solution is made up of several components:

  • ss7boxd - a MTP3 routing daemon controlling all SS7 links and talking to kernel level MTP2 module
  • ss7boost - an ISUP protocol engine talking to ss7boxd and sangoma_mgd
  • sangoma_mgd - a Media gateway daemon & Woomera server sitting between Woomera clients & ss7boost - sending voice between PSTN & connected Woomera clients
  • Woomera clients - any telephony engine speaking Woomera protocol - Asterisk/CallWeaver/FreeSwitch
Woomera client (eg chan_woomera in Asterisk) can be run on a separate machine from the one that has Sangoma PSTN cards in it. Also there is nothing that forbids a setup with many Asterisks talking to a single SMG over Woomera/RTP. Such a setup automatically load balances call processing (advanced routing logic, prepaid billing, media transcoding, SIP termination etc) across a number of machines.
For the sake of this article we are going to call a setup with Asterisk & SMG on a single machine - a centralized one, and a setup with one or many Asterisk installations on dedicated machines a distributed one.

Methodology:

To test the performance of a basic SMG setup without any SIP termination or media transcoding we are using 3 SUN servers each equipped with a 3GHz AMD Opteron Dual Core CPU and 1 GB of RAM.

A single test configuration can measure performance of both distributed and centralized setups.
One server is dedicated to a centralized SMG + Asterisk and connects over 16 E1s to a distributed setup consisting of two servers, one dedicated to SMG and one dedicated to Asterisk.

The first test procedure consists of measuring system load (5m average) and CPU usage in 20s intervals on all servers while setting up 2 additional calls between ss7 Point Codes every 60s until 490 calls are connected.

We also monitor the volume of RTP traffic between SMG and Asterisk in distributed setup.

The second test is a call generator simulation when one side initiates every second a one second call setup/termination loop with MusicOnHold on the caller's leg. Every 60 seconds a new parallel application thread starts generating calls until ss7 link reaches 50% capacity.

Configuration:

Relevant SMG, Asterisk and system config files:

boxAboxS boxSA
extensions.conf extensions.conf
 ss7boxd.confss7box.conf
 ss7boost.conf
ss7boost.conf
sangoma_mdg.conf sangoma_mdg.conf
woomera.conf woomera.conf
Fig. 2 - SMG test setup schema

 

 

Results:

  • Test I, CPU utilization and system load vs number of active calls

Fig. 3 - CPU utilization on all 3 servers during test I

Fig. 4 - System load on all 3 servers

  • Test I, Woomera RTP traffic volume vs active calls
Fig. 5 - Traffic volume between Asterisk and SMG servers


  • Test I, Detailed CPU usage table for 490 calls
490 callsCPU utilization
UserSystemHW IRQSW IRQIdleLoad
boxA9%8%0%5%78%1,5
boxS3%17%6%8%66%24,5
boxSA13%25%7%12%43%116,8
Fig. 6 - CPU utilization by resource during test I


  • Test II, CPU utilization vs number of call setups

Fig. 7 - CPU utilization by during test II

Conclusions:

A single SUN x2100, 3GHz Dual Core is ideal for up to 16E1 with centralized setup when performing trivial tasks like IVRs with low call setup ratio and no transcoding nor SIP termination as there will not be enough CPU (<40%) left for sending the full traffic out of Asterisk.

A minimal distributed setup with two SUN x2100 servers can handle both 16E1s SS7 termination and have enough room (~60% CPU free) for additional routing logic, local database, transcoding, SIP termination even with high volume of call setups per second.

If You don't want to invest in more than one server and need advanced routing logic, transcoding and/or SIP termination consider SUN x2200 with two dual core CPUs.

Note:

Quad Cores servers are not necessarily faster unless You are brave enough to try custom Linux kernels that do better job at IRQ scheduling across 4 cores. SUN x2100/x2200 servers outperform Intel Quad Core servers in the same price range at the moment of writing this article.

Also fresh kernel like 2.6.24&5 in Fedora 8 & 9 behave really bad in this scenario Embarassed. SMG and Asterisk generate twice as much CPU load with the new kernels thus forbidding the use of this configuration for more then 200 simultaneous calls.

 

Powered By Joomla Tags

Last Updated ( Wednesday, 06 August 2008 11:12 )
 
 
English (Angielski)