FreeSWITCH performance on Intel Atom CPU

There are multiple low-power, fanless  appliances on the market, and most of them are powered by Intel Atom processors. I needed an estimation how well an Atom would perform for a FreeSWITCH PBX application.

In this test, I use two Acer Aspire One notebooks with different processors:

  • atom01: Atom N2600 (2 cores, 4 virtual CPUs, 512KB cache and 600MHz per virtual CPU, 12768.02 BogoMIPS)
  • atom02: Atom N570 (2 cores, 4 virtual CPUs, 512KB cache and 1000MHz per virtual CPU, 13302.08 BogoMIPS)

Both notebooks are running 32-bit Debian 7 Wheezy (Kernel version 3.2.0-4-686-pae), and FreeSWITCH version 1.2.13 from pre-built Debian packages.

Test results summary

All calls in this test used transcoding between G.711alaw and G.722. The bottleneck in performance was always at the N2600 (atom01), because of slower CPU. In general, N570 can handle approximately 30% higher load than N2600.

With 10 concurrent calls (21 channels on atom01 and 20 channels on atom02), there is no voice distortion and new call processing does not disturb the ongoing calls. Each virtual CPU is busy at 20-25%

With 20 concurrent calls (41 channels on atom01 and 40 cannels on atom02), there is some minor voice distortion, especially during incoming calls, but quality s still acceptable.

With 27 concurrent calls (55 and 54 channels), voice distortions were too high and not acceptable. Every virtual CPU on atom01 was busy at around 50%, which means full load for the whole CPU.

With 20 concurrent calls without transcoding (PCMA only in all call legs), each CPU core on atom01 was utilized at around 9-10%. So, theoretically the platform can handle up to 40-50 simultaneous calls in non-transcoding mode.

Only the voice quality was tested. CPS was not tested, and it depends heavily on the complexity of the dialplan. But the overall response of the system was quite acceptable.

Testing details

I took my minimal FreeSWITCH configuration for the tests, and extended it as follows:

atom01

sip_profiles/external/itsp.xml registers at my vPBX, so that I could initiate the calls. Incoming calls are sent to extension 500.

sip_profiles/external/atom02.xml defines the gateway that points to atom02:

<include>
  <gateway name="atom02">
    <param name="register" value="false"/>
    <param name="proxy" value="192.168.1.61:5080"/>
    <param name="ping" value="27"/>
  </gateway>
</include>

dialplan/public/15_bulkmatch.xml consists of 100 identical conditions, like shown below. It does not do anything useful, and it’s only used to make FreeSWITCH  busy processing the dialplan:

<include>
  <extension name="bmatch" continue="true">
    <condition field="destination_number" expression="^(\d+)$">
      <action application="set" data="xxxxx=$1"/>
    </condition>
  </extension>
  <extension name="bmatch" continue="true">
    <condition field="destination_number" expression="^(\d+)$">
      <action application="set" data="xxxxx=$1"/>
    </condition>
  </extension>
......

dialplan/public/20_perftest.xmltakes the call at extension 500 and plays delayed echo. When I press *1, it makes a new call leg to atom02 in G711alaw codec, and atom02 makes a new call leg back to atom01 in G.722:

<include>
  <extension name="500">
    <condition field="destination_number" expression="^500$">
      <action application="answer"/>
      <action application="bind_meta_app" data="1 a si transfer::501 XML ${context}"/>
      <action application="delay_echo" data="1000"/>
    </condition>
  </extension>
  <extension name="501">
    <condition field="destination_number" expression="^501$">
      <action application="playback" data="tone_stream://%(100,100,1400,2060,2450,2600)"/>
      <action application="unbind_meta_app" data=""/>
      <action application="bridge" data="{absolute_codec_string=PCMA}sofia/gateway/atom02/600"/>
    </condition>
  </extension>  
</include>

atom02

sip_profiles/external/atom01.xml defines the gateway pointing to atom01:

<include>
  <gateway name="atom01">
    <param name="register" value="false"/>
    <param name="proxy" value="192.168.1.60:5080"/>
    <param name="ping" value="27"/>
  </gateway>
</include>

dialplan/public/15_bulkmatch.xml is identical to that on atom01.

dialplan/public/20_perftest.xml answers the call at extension 600 and places a new call to extension 500 at atom01:

<include>
    <extension name="600">
    <condition field="destination_number" expression="^600$">
      <action application="answer"/>
      <action application="bridge" data="{max_forwards=65}{absolute_codec_string=G722}sofia/gateway/atom01/500"/>
    </condition>
  </extension>
</include>

When non-transcoding tests are made, the codec string is changed to PCMA.

Advertisements

, , , , , ,

  1. FreeSWITCH performance test on PC Engines APU | TXLAB

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: