I have no such problems on debian . I use debian 5 with 2.6.18 kernel which is what Is recommended Are you using tmpfs ?? Jay On 22/04/2011, at 3:26 AM, Christian Löschenkohl<christian.loeschenkohl@xpirio.com> wrote:

hi

we did use debian too and had such performance issues (sip packet delays, low cps). after using centos 64bit (as advised by the devs) all performance problems are gone.

br

On 2011-04-21 18:24, Antonio Teixeira wrote:

...

Hello List.

I'm currently integrating an IVR in python together with freeswitch using mod_python and ESL and my life has been well until ... The flow of calls went over 80 simultaneous calls. Now freeswitch starts sending packets with huge delays ( even when establishing the call , mainly the 200 ) and firing up the IVR with tons of delay up to 20 seconds.

So i searched the wiki forums and mailing list:

Put freeswitch on a diet , trimmed modules.conf Played with the ulimit stuff. Played with the IVRS to reduce load to a minimum and i was able to squeeze more 5 calls of performance.

The problem is :

Top shows top - 16:14:33 up 35 days, 8:15, 3 users, load average: 1.92, 1.76, 1.78 Tasks: 133 total, 1 running, 132 sleeping, 0 stopped, 0 zombie Cpu(s): 1.4%us, 3.3%sy, 0.0%ni, 94.6%id, 0.0%wa, 0.3%hi, 0.5%si, 0.0%st Mem: 8193336k total, 1639156k used, 6554180k free, 177208k buffers Swap: 19534904k total, 0k used, 19534904k free, 1062272k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 31361 yadayada 20 0 716m 164m 9628 S 73 2.1 155:17.85 freeswitch

Freeswitch goes up to 150 % and puff there goes the MOS down to 0.

Some basic System Info : Debian 6.0 ( i heard the timming module is affected by Debian , but if the CPU % gets lower than 95% everything will be more stable) Python 2.5

2 x Intel(R) Xeon(R) CPU E5506 @ 2.13GHz 8 GB of Ram

as you can see 94 % of the "Cpu Power" is sleeping :\

It appears freeswitch is only capable of using let's say "one cpu"/thread ?? Do you guys recommend simply starting more instances or redoing the IVR stuff.

Hope you guys can help me out.

Thanks António Teixeira

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

-- Ing. Christian Löschenkohl Technische Leitung, Forschung & Entwicklung VoIP

xpirio Telekommunikation & Service GmbH Lakeside B04 9020 Klagenfurt Austria

T +43 5 77 11 - 1000 F +43 5 77 11 - 1002 E christian.loeschenkohl@xpirio.com

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

Freeswitch is targeted for CentOS 5.3, which in my opinion quite short sighted for the developers to do this. However with the limited size of developers and testers, I'm afraid there's not much platforms we can throughly test and actually say "okay, FS will run flawlessly on X distro" However you can always try messing with the CFLAG's mtune option and see what it produces for you... 2011/4/22 Christian Löschenkohl <christian.loeschenkohl@xpirio.com>:

hi

if you refer to my e-mail

yes, we do use tmpfs on both variants but - delays occur with concurrent calls > 80-100 - cps is limited to 5-10 on debian, with centos 30 cps and more are no problem at all

also cpu load, stability and overall performace have been much better since using centos

i just found out for me that debian works not as good for me as centos does. btw. everywhere else debian is 1st choice (desktop, lamp, db etc.)

br

On 2011-04-21 23:04, Jay Binks wrote:

...

I have no such problems on debian .

I use debian 5 with 2.6.18 kernel which is what Is recommended

Are you using tmpfs ??

Jay

On 22/04/2011, at 3:26 AM, Christian Löschenkohl<christian.loeschenkohl@xpirio.com>  wrote:

...

hi

we did use debian too and had such performance issues (sip packet delays, low cps). after using centos 64bit (as advised by the devs) all performance problems are gone.

br

On 2011-04-21 18:24, Antonio Teixeira wrote:

...

Hello List.

I'm currently integrating an IVR in python together with freeswitch using mod_python and ESL and my life has been well until ... The flow of calls went over 80 simultaneous calls. Now freeswitch starts sending packets with huge delays ( even when establishing the call , mainly the 200 ) and firing up the IVR with tons of delay up to 20 seconds.

So i searched the wiki forums and mailing list:

Put freeswitch on a diet , trimmed modules.conf Played with the ulimit stuff. Played with the IVRS to reduce load to a minimum and i was able to squeeze more 5 calls of performance.

The problem is :

Top shows top - 16:14:33 up 35 days,  8:15,  3 users,  load average: 1.92, 1.76, 1.78 Tasks: 133 total,   1 running, 132 sleeping,   0 stopped,   0 zombie Cpu(s):  1.4%us,  3.3%sy,  0.0%ni, 94.6%id,  0.0%wa,  0.3%hi,  0.5%si,  0.0%st Mem:   8193336k total,  1639156k used,  6554180k free,   177208k buffers Swap: 19534904k total,        0k used, 19534904k free,  1062272k cached

   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND 31361 yadayada      20   0  716m 164m 9628 S   73  2.1 155:17.85 freeswitch

Freeswitch goes up to 150 % and puff there goes the MOS down to 0.

Some basic System Info : Debian 6.0 ( i heard the timming module is affected by Debian , but if the CPU % gets lower than 95% everything will be more stable) Python 2.5

2 x Intel(R) Xeon(R) CPU           E5506  @ 2.13GHz 8 GB of Ram

as you can see 94 % of the "Cpu Power" is sleeping :\

It appears freeswitch is only capable of using let's say "one cpu"/thread ?? Do you guys recommend simply starting more instances or redoing the IVR stuff.

Hope you guys can help me out.

Thanks António Teixeira

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

-- Ing. Christian Löschenkohl Technische Leitung, Forschung&  Entwicklung VoIP

xpirio Telekommunikation&  Service GmbH Lakeside B04 9020 Klagenfurt Austria

T  +43 5 77 11 - 1000 F  +43 5 77 11 - 1002 E  christian.loeschenkohl@xpirio.com

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

-- Ing. Christian Löschenkohl Technische Leitung, Forschung & Entwicklung VoIP

xpirio Telekommunikation & Service GmbH Lakeside B04 9020 Klagenfurt Austria

T  +43 5 77 11 - 1000 F  +43 5 77 11 - 1002 E  christian.loeschenkohl@xpirio.com

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

FreeSWITCH runs well on many platforms. However, the devs are painfully aware that bleeding edge distros have bleeding edge gcc compilers and other interesting issues. That being said, CentOS 5.x is "stable" in that it's old and boring, therefore it has the least amount of drama. OTOH, some of our users have been having great success with Arch Linux (IRC:bougeyman) and FS, even though Arch uses very recent kernels. Bottom line: if you know what you're doing then you can probably run FS anywhere. If you don't know what you're doing then stick with CentOS 5.x or Debian Lenny until you do. (I run then both with zero issues, compiling latest git each day.) -MC On Fri, Apr 22, 2011 at 10:03 AM, curriegrad2004 <curriegrad2004@gmail.com>wrote:

Freeswitch is targeted for CentOS 5.3, which in my opinion quite short sighted for the developers to do this. However with the limited size of developers and testers, I'm afraid there's not much platforms we can throughly test and actually say "okay, FS will run flawlessly on X distro"

However you can always try messing with the CFLAG's mtune option and see what it produces for you...

2011/4/22 Christian Löschenkohl <christian.loeschenkohl@xpirio.com>:

...

hi

if you refer to my e-mail

yes, we do use tmpfs on both variants but - delays occur with concurrent calls > 80-100 - cps is limited to 5-10 on debian, with centos 30 cps and more are no problem at all

also cpu load, stability and overall performace have been much better since using centos

i just found out for me that debian works not as good for me as centos does. btw. everywhere else debian is 1st choice (desktop, lamp, db etc.)

br

On 2011-04-21 23:04, Jay Binks wrote:

...

I have no such problems on debian .

I use debian 5 with 2.6.18 kernel which is what Is recommended

Are you using tmpfs ??

Jay

On 22/04/2011, at 3:26 AM, Christian Löschenkohl< christian.loeschenkohl@xpirio.com> wrote:

...

hi

we did use debian too and had such performance issues (sip packet delays, low cps). after using centos 64bit (as advised by the devs) all performance problems are gone.

br

On 2011-04-21 18:24, Antonio Teixeira wrote:

...

Hello List.

I'm currently integrating an IVR in python together with freeswitch using mod_python and ESL and my life has been well until ... The flow of calls went over 80 simultaneous calls. Now freeswitch starts sending packets with huge delays ( even when establishing the call , mainly the 200 ) and firing up the IVR with tons of delay up to 20 seconds.

So i searched the wiki forums and mailing list:

Put freeswitch on a diet , trimmed modules.conf Played with the ulimit stuff. Played with the IVRS to reduce load to a minimum and i was able to squeeze more 5 calls of performance.

The problem is :

Top shows top - 16:14:33 up 35 days, 8:15, 3 users, load average: 1.92, 1.76, 1.78 Tasks: 133 total, 1 running, 132 sleeping, 0 stopped, 0 zombie Cpu(s): 1.4%us, 3.3%sy, 0.0%ni, 94.6%id, 0.0%wa, 0.3%hi, 0.5%si, 0.0%st Mem: 8193336k total, 1639156k used, 6554180k free, 177208k buffers Swap: 19534904k total, 0k used, 19534904k free, 1062272k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 31361 yadayada 20 0 716m 164m 9628 S 73 2.1 155:17.85 freeswitch

Freeswitch goes up to 150 % and puff there goes the MOS down to 0.

Some basic System Info : Debian 6.0 ( i heard the timming module is affected by Debian , but if the CPU % gets lower than 95% everything will be more stable) Python 2.5

2 x Intel(R) Xeon(R) CPU E5506 @ 2.13GHz 8 GB of Ram

as you can see 94 % of the "Cpu Power" is sleeping :\

It appears freeswitch is only capable of using let's say "one cpu"/thread ?? Do you guys recommend simply starting more instances or redoing the IVR stuff.

Hope you guys can help me out.

Thanks António Teixeira

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

-- Ing. Christian Löschenkohl Technische Leitung, Forschung& Entwicklung VoIP

xpirio Telekommunikation& Service GmbH Lakeside B04 9020 Klagenfurt Austria

T +43 5 77 11 - 1000 F +43 5 77 11 - 1002 E christian.loeschenkohl@xpirio.com

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

-- Ing. Christian Löschenkohl Technische Leitung, Forschung & Entwicklung VoIP

xpirio Telekommunikation & Service GmbH Lakeside B04 9020 Klagenfurt Austria

T +43 5 77 11 - 1000 F +43 5 77 11 - 1002 E christian.loeschenkohl@xpirio.com

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

You can definitely use the event socket. Heck, you can even use Python if you want to. The dev team wrote ESL specifically for cases like these - where you want to control FS externally. ESL beats the pants off AGI scripts. It gives you complete control over the system. That all being said, you can do all sorts of stuff with Lua dialplan scripts. Check out chapter 7 of the FreeSWITCH book for some nice examples. Lua is lightweight and easy to learn. It's a good alternative for many cases. Check it out... -MC On Fri, Apr 22, 2011 at 12:39 PM, Antonio Teixeira <eagle.antonio@gmail.com>wrote:

Well i totally agree with the Dev team decision , it would be impossible for a DEV team to "get it right" in all the distros that's why i started this post.

But we also need to take into consideration that we are talking about IVR Processing , not auto-*attendants* or simply call pass trough. This means heavy use of TTS / ASR , Database Logic and Scripts , GetDigits and the works.

I use python alot , but i think the mod_python is not the best tool for this job i admit that , that's why im currently looking for other solutions. I'm thinking in using mod_socket , but that scares me ( letś say bad experiences with Asterisk AGI) Or Mod Curl

The main problem is that some IVR are extremely complex , like questionnaires , etc.

It would be great if we could mod_event_zmq to control the calls [?]

Just to Sum it UP so far , so i can later add it to the wiki.

Use Cent OS 64. Use tmpfs for all the databases.

Thank you all for helping and Happy Eastern. António Teixeira

2011/4/22 Michael Collins <msc@freeswitch.org>

...

FreeSWITCH runs well on many platforms. However, the devs are painfully aware that bleeding edge distros have bleeding edge gcc compilers and other interesting issues. That being said, CentOS 5.x is "stable" in that it's old and boring, therefore it has the least amount of drama. OTOH, some of our users have been having great success with Arch Linux (IRC:bougeyman) and FS, even though Arch uses very recent kernels.

Bottom line: if you know what you're doing then you can probably run FS anywhere. If you don't know what you're doing then stick with CentOS 5.x or Debian Lenny until you do. (I run then both with zero issues, compiling latest git each day.)

-MC

On Fri, Apr 22, 2011 at 10:03 AM, curriegrad2004 < curriegrad2004@gmail.com> wrote:

...

Freeswitch is targeted for CentOS 5.3, which in my opinion quite short sighted for the developers to do this. However with the limited size of developers and testers, I'm afraid there's not much platforms we can throughly test and actually say "okay, FS will run flawlessly on X distro"

However you can always try messing with the CFLAG's mtune option and see what it produces for you...

2011/4/22 Christian Löschenkohl <christian.loeschenkohl@xpirio.com>:

...

hi

if you refer to my e-mail

yes, we do use tmpfs on both variants but - delays occur with concurrent calls > 80-100 - cps is limited to 5-10 on debian, with centos 30 cps and more are no problem at all

also cpu load, stability and overall performace have been much better since using centos

i just found out for me that debian works not as good for me as centos does. btw. everywhere else debian is 1st choice (desktop, lamp, db etc.)

br

On 2011-04-21 23:04, Jay Binks wrote:

...

I have no such problems on debian .

I use debian 5 with 2.6.18 kernel which is what Is recommended

Are you using tmpfs ??

Jay

On 22/04/2011, at 3:26 AM, Christian Löschenkohl< christian.loeschenkohl@xpirio.com> wrote:

...

hi

we did use debian too and had such performance issues (sip packet delays, low cps). after using centos 64bit (as advised by the devs) all performance problems are gone.

br

On 2011-04-21 18:24, Antonio Teixeira wrote:

> Hello List. > > I'm currently integrating an IVR in python together with freeswitch using mod_python and ESL and my life has been well until ... > The flow of calls went over 80 simultaneous calls. > Now freeswitch starts sending packets with huge delays ( even when establishing the call , mainly the 200 ) and firing up the IVR with tons of delay up to 20 seconds. > > So i searched the wiki forums and mailing list: > > Put freeswitch on a diet , trimmed modules.conf > Played with the ulimit stuff. > Played with the IVRS to reduce load to a minimum and i was able to squeeze more 5 calls of performance. > > The problem is : > > Top shows > top - 16:14:33 up 35 days, 8:15, 3 users, load average: 1.92, 1.76, 1.78 > Tasks: 133 total, 1 running, 132 sleeping, 0 stopped, 0 zombie > Cpu(s): 1.4%us, 3.3%sy, 0.0%ni, 94.6%id, 0.0%wa, 0.3%hi, 0.5%si, 0.0%st > Mem: 8193336k total, 1639156k used, 6554180k free, 177208k buffers > Swap: 19534904k total, 0k used, 19534904k free, 1062272k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 31361 yadayada 20 0 716m 164m 9628 S 73 2.1 155:17.85 freeswitch > > Freeswitch goes up to 150 % and puff there goes the MOS down to 0. > > > Some basic System Info : > Debian 6.0 ( i heard the timming module is affected by Debian , but if the CPU % gets lower than 95% everything will be more stable) > Python 2.5 > > 2 x Intel(R) Xeon(R) CPU E5506 @ 2.13GHz > 8 GB of Ram > > as you can see 94 % of the "Cpu Power" is sleeping :\ > > > It appears freeswitch is only capable of using let's say "one cpu"/thread ?? > Do you guys recommend simply starting more instances or redoing the IVR stuff. > > > Hope you guys can help me out. > > Thanks > António Teixeira > > > > > > > > > > > > > > > _______________________________________________ > FreeSWITCH-users mailing list > FreeSWITCH-users@lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users > http://www.freeswitch.org

-- Ing. Christian Löschenkohl Technische Leitung, Forschung& Entwicklung VoIP

xpirio Telekommunikation& Service GmbH Lakeside B04 9020 Klagenfurt Austria

T +43 5 77 11 - 1000 F +43 5 77 11 - 1002 E christian.loeschenkohl@xpirio.com

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

-- Ing. Christian Löschenkohl Technische Leitung, Forschung & Entwicklung VoIP

xpirio Telekommunikation & Service GmbH Lakeside B04 9020 Klagenfurt Austria

T +43 5 77 11 - 1000 F +43 5 77 11 - 1002 E christian.loeschenkohl@xpirio.com

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

Use wireshark to trace the call and then read header Sent from my BlackBerry® wireless handheld -----Original Message----- From: "Sam Oredoyin" <sam.oredoyin@gmail.com> Sender: freeswitch-users-bounces@lists.freeswitch.org Date: Fri, 22 Apr 2011 22:15:31 To: 'FreeSWITCH Users Help'<freeswitch-users@lists.freeswitch.org> Reply-To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Subject: [Freeswitch-users] Reading Channel Variables on B-Leg - To display Callee name _______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

On Fri, Apr 22, 2011 at 3:22 PM, Sam Oredoyin <sam.oredoyin@gmail.com>wrote:

Thanks Hasnain,

I need to read it in the dialplan, so dialplan can insert the B-Leg Remote-Party-ID into the caller display.

Send the inbound call to the "info" dialplan app and look at the console output. There are many sip_xxx variables you can choose from. Find the one you want and use it. -MC

M Pieter Eduard -----Original Message----- From: Michael Collins <msc@freeswitch.org> Sender: freeswitch-users-bounces@lists.freeswitch.org Date: Fri, 22 Apr 2011 13:26:55 To: FreeSWITCH Users Help<freeswitch-users@lists.freeswitch.org> Reply-To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Subject: Re: [Freeswitch-users] Tuning Up Freeswitch _______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

ESL would be best as you can offload the processing to another server - potentially a load balanced cluster. Steve on iPhone On 23 Apr 2011, at 08:51, Antonio Teixeira <eagle.antonio@gmail.com> wrote:

Hello Michael & The rest.

What i'm trying to find is the solution with the highest performance for IVR Applications. And squeezing the last bit of performance out of freeswitch is a needed path specially on a industry that does second by second billing :P i'm going to do some performance testing with Lua , ESL And Mod Curl and of course python and measure some performance data and will post it later.

A/T

2011/4/22 Michael Collins <msc@freeswitch.org> You can definitely use the event socket. Heck, you can even use Python if you want to. The dev team wrote ESL specifically for cases like these - where you want to control FS externally. ESL beats the pants off AGI scripts. It gives you complete control over the system.

That all being said, you can do all sorts of stuff with Lua dialplan scripts. Check out chapter 7 of the FreeSWITCH book for some nice examples. Lua is lightweight and easy to learn. It's a good alternative for many cases. Check it out...

-MC

On Fri, Apr 22, 2011 at 12:39 PM, Antonio Teixeira <eagle.antonio@gmail.com> wrote: Well i totally agree with the Dev team decision , it would be impossible for a DEV team to "get it right" in all the distros that's why i started this post.

But we also need to take into consideration that we are talking about IVR Processing , not auto-attendants or simply call pass trough. This means heavy use of TTS / ASR , Database Logic and Scripts , GetDigits and the works.

I use python alot , but i think the mod_python is not the best tool for this job i admit that , that's why im currently looking for other solutions. I'm thinking in using mod_socket , but that scares me ( letś say bad experiences with Asterisk AGI) Or Mod Curl

The main problem is that some IVR are extremely complex , like questionnaires , etc.

It would be great if we could mod_event_zmq to control the calls <330.gif>

Just to Sum it UP so far , so i can later add it to the wiki.

Use Cent OS 64. Use tmpfs for all the databases.

Thank you all for helping and Happy Eastern. António Teixeira

2011/4/22 Michael Collins <msc@freeswitch.org> FreeSWITCH runs well on many platforms. However, the devs are painfully aware that bleeding edge distros have bleeding edge gcc compilers and other interesting issues. That being said, CentOS 5.x is "stable" in that it's old and boring, therefore it has the least amount of drama. OTOH, some of our users have been having great success with Arch Linux (IRC:bougeyman) and FS, even though Arch uses very recent kernels.

Bottom line: if you know what you're doing then you can probably run FS anywhere. If you don't know what you're doing then stick with CentOS 5.x or Debian Lenny until you do. (I run then both with zero issues, compiling latest git each day.)

-MC

On Fri, Apr 22, 2011 at 10:03 AM, curriegrad2004 <curriegrad2004@gmail.com> wrote: Freeswitch is targeted for CentOS 5.3, which in my opinion quite short sighted for the developers to do this. However with the limited size of developers and testers, I'm afraid there's not much platforms we can throughly test and actually say "okay, FS will run flawlessly on X distro"

However you can always try messing with the CFLAG's mtune option and see what it produces for you...

2011/4/22 Christian Löschenkohl <christian.loeschenkohl@xpirio.com>:

...

hi

if you refer to my e-mail

yes, we do use tmpfs on both variants but - delays occur with concurrent calls > 80-100 - cps is limited to 5-10 on debian, with centos 30 cps and more are no problem at all

also cpu load, stability and overall performace have been much better since using centos

i just found out for me that debian works not as good for me as centos does. btw. everywhere else debian is 1st choice (desktop, lamp, db etc.)

br

On 2011-04-21 23:04, Jay Binks wrote:

...

I have no such problems on debian .

I use debian 5 with 2.6.18 kernel which is what Is recommended

Are you using tmpfs ??

Jay

On 22/04/2011, at 3:26 AM, Christian Löschenkohl<christian.loeschenkohl@xpirio.com> wrote:

...

hi

we did use debian too and had such performance issues (sip packet delays, low cps). after using centos 64bit (as advised by the devs) all performance problems are gone.

br

On 2011-04-21 18:24, Antonio Teixeira wrote:

...

Hello List.

I'm currently integrating an IVR in python together with freeswitch using mod_python and ESL and my life has been well until ... The flow of calls went over 80 simultaneous calls. Now freeswitch starts sending packets with huge delays ( even when establishing the call , mainly the 200 ) and firing up the IVR with tons of delay up to 20 seconds.

So i searched the wiki forums and mailing list:

Put freeswitch on a diet , trimmed modules.conf Played with the ulimit stuff. Played with the IVRS to reduce load to a minimum and i was able to squeeze more 5 calls of performance.

The problem is :

Top shows top - 16:14:33 up 35 days, 8:15, 3 users, load average: 1.92, 1.76, 1.78 Tasks: 133 total, 1 running, 132 sleeping, 0 stopped, 0 zombie Cpu(s): 1.4%us, 3.3%sy, 0.0%ni, 94.6%id, 0.0%wa, 0.3%hi, 0.5%si, 0.0%st Mem: 8193336k total, 1639156k used, 6554180k free, 177208k buffers Swap: 19534904k total, 0k used, 19534904k free, 1062272k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 31361 yadayada 20 0 716m 164m 9628 S 73 2.1 155:17.85 freeswitch

Freeswitch goes up to 150 % and puff there goes the MOS down to 0.

Some basic System Info : Debian 6.0 ( i heard the timming module is affected by Debian , but if the CPU % gets lower than 95% everything will be more stable) Python 2.5

2 x Intel(R) Xeon(R) CPU E5506 @ 2.13GHz 8 GB of Ram

as you can see 94 % of the "Cpu Power" is sleeping :\

It appears freeswitch is only capable of using let's say "one cpu"/thread ?? Do you guys recommend simply starting more instances or redoing the IVR stuff.

Hope you guys can help me out.

Thanks António Teixeira

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

-- Ing. Christian Löschenkohl Technische Leitung, Forschung& Entwicklung VoIP

xpirio Telekommunikation& Service GmbH Lakeside B04 9020 Klagenfurt Austria

T +43 5 77 11 - 1000 F +43 5 77 11 - 1002 E christian.loeschenkohl@xpirio.com

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

-- Ing. Christian Löschenkohl Technische Leitung, Forschung & Entwicklung VoIP

xpirio Telekommunikation & Service GmbH Lakeside B04 9020 Klagenfurt Austria

T +43 5 77 11 - 1000 F +43 5 77 11 - 1002 E christian.loeschenkohl@xpirio.com

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

Good Morning. @ Steven, Thanks for the idea i will make a prototype in Python , and will send you guysthe performance data when i have it. @ François You probably want this. http://wiki.freeswitch.org/wiki/XML_Switch_Configuration 'sessions-per-second' - throttling mechanism, the switch will only create this many channels at most, per second. 2011/4/25 François Delawarde <fdelawarde@wirelessmundi.com>

I also experienced a huge delay issue when attacked by mister "friendly-scanner". The machine was not overloaded and call setup was working well but with a 10-20 seconds delay. Note that the delay was only with SIP answers, and once RTP was setup the audio was perfect.

Following advices from http://wiki.freeswitch.org/wiki/QoS solved it in my case. Is there a mechanism in FS that could detect huge call setup delay and simply reject calls?

François.

On Sat, 2011-04-23 at 14:46 +0100, Steven Ayre wrote:

...

ESL would be best as you can offload the processing to another server - potentially a load balanced cluster.

Steve on iPhone

On 23 Apr 2011, at 08:51, Antonio Teixeira <eagle.antonio@gmail.com> wrote:

...

Hello Michael & The rest.

What i'm trying to find is the solution with the highest performance for IVR Applications. And squeezing the last bit of performance out of freeswitch is a needed path specially on a industry that does second by second billing :P i'm going to do some performance testing with Lua , ESL And Mod Curl and of course python and measure some performance data and will post it later.

A/T

2011/4/22 Michael Collins <msc@freeswitch.org> You can definitely use the event socket. Heck, you can even use Python if you want to. The dev team wrote ESL specifically for cases like these - where you want to control FS externally. ESL beats the pants off AGI scripts. It gives you complete control over the system.

That all being said, you can do all sorts of stuff with Lua dialplan scripts. Check out chapter 7 of the FreeSWITCH book for some nice examples. Lua is lightweight and easy to learn. It's a good alternative for many cases. Check it out...

-MC

On Fri, Apr 22, 2011 at 12:39 PM, Antonio Teixeira <eagle.antonio@gmail.com> wrote: Well i totally agree with the Dev team decision , it would be impossible for a DEV team to "get it right" in all the distros that's why i started this post.

But we also need to take into consideration that we are talking about IVR Processing , not auto-attendants or simply call pass trough. This means heavy use of TTS / ASR , Database Logic and Scripts , GetDigits and the works.

I use python alot , but i think the mod_python is not the best tool for this job i admit that , that's why im currently looking for other solutions. I'm thinking in using mod_socket , but that scares me ( letś say bad experiences with Asterisk AGI) Or Mod Curl

The main problem is that some IVR are extremely complex , like questionnaires , etc.

It would be great if we could mod_event_zmq to control the calls <330.gif>

Just to Sum it UP so far , so i can later add it to the wiki.

Use Cent OS 64. Use tmpfs for all the databases.

Thank you all for helping and Happy Eastern. António Teixeira

2011/4/22 Michael Collins <msc@freeswitch.org> FreeSWITCH runs well on many platforms. However, the devs are painfully aware that bleeding edge distros have bleeding edge gcc compilers and other interesting issues. That being said, CentOS 5.x is "stable" in that it's old and boring, therefore it has the least amount of drama. OTOH, some of our users have been having great success with Arch Linux (IRC:bougeyman) and FS, even though Arch uses very recent kernels.

Bottom line: if you know what you're doing then you can probably run FS anywhere. If you don't know what you're doing then stick with CentOS 5.x or Debian Lenny until you do. (I run then both with zero issues, compiling latest git each day.)

-MC

On Fri, Apr 22, 2011 at 10:03 AM, curriegrad2004 <curriegrad2004@gmail.com> wrote: Freeswitch is targeted for CentOS 5.3, which in my opinion quite short sighted for the developers to do this. However with the limited size of developers and testers, I'm afraid there's not much platforms we can throughly test and actually say "okay, FS will run flawlessly on X distro"

However you can always try messing with the CFLAG's mtune option and see what it produces for you...

2011/4/22 Christian Löschenkohl <christian.loeschenkohl@xpirio.com>:

> hi > > if you refer to my e-mail > > yes, we do use tmpfs on both variants but > - delays occur with concurrent calls > 80-100 > - cps is limited to 5-10 on debian, with centos 30 cps and more are no problem at all > > also cpu load, stability and overall performace have been much better since using centos > > i just found out for me that debian works not as good for me as centos does. > btw. everywhere else debian is 1st choice (desktop, lamp, db etc.) > > br > > > On 2011-04-21 23:04, Jay Binks wrote: > >> I have no such problems on debian . >> >> I use debian 5 with 2.6.18 kernel which is what Is recommended >> >> Are you using tmpfs ?? >> >> Jay >> >> >> >> On 22/04/2011, at 3:26 AM, Christian Löschenkohl< christian.loeschenkohl@xpirio.com> wrote: >> >>> hi >>> >>> we did use debian too and had such performance issues (sip packet delays, low cps). >>> after using centos 64bit (as advised by the devs) all performance problems are gone. >>> >>> br >>> >>> On 2011-04-21 18:24, Antonio Teixeira wrote: >>> >>>> Hello List. >>>> >>>> I'm currently integrating an IVR in python together with freeswitch using mod_python and ESL and my life has been well until ... >>>> The flow of calls went over 80 simultaneous calls. >>>> Now freeswitch starts sending packets with huge delays ( even when establishing the call , mainly the 200 ) and firing up the IVR with tons of delay up to 20 seconds. >>>> >>>> So i searched the wiki forums and mailing list: >>>> >>>> Put freeswitch on a diet , trimmed modules.conf >>>> Played with the ulimit stuff. >>>> Played with the IVRS to reduce load to a minimum and i was able to squeeze more 5 calls of performance. >>>> >>>> The problem is : >>>> >>>> Top shows >>>> top - 16:14:33 up 35 days, 8:15, 3 users, load average: 1.92, 1.76, 1.78 >>>> Tasks: 133 total, 1 running, 132 sleeping, 0 stopped, 0 zombie >>>> Cpu(s): 1.4%us, 3.3%sy, 0.0% ni, 94.6%id, 0.0%wa, 0.3%hi, 0.5% si, 0.0%st >>>> Mem: 8193336k total, 1639156k used, 6554180k free, 177208k buffers >>>> Swap: 19534904k total, 0k used, 19534904k free, 1062272k cached >>>> >>>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND >>>> 31361 yadayada 20 0 716m 164m 9628 S 73 2.1 155:17.85 freeswitch >>>> >>>> Freeswitch goes up to 150 % and puff there goes the MOS down to 0. >>>> >>>> >>>> Some basic System Info : >>>> Debian 6.0 ( i heard the timming module is affected by Debian , but if the CPU % gets lower than 95% everything will be more stable) >>>> Python 2.5 >>>> >>>> 2 x Intel(R) Xeon(R) CPU E5506 @ 2.13GHz >>>> 8 GB of Ram >>>> >>>> as you can see 94 % of the "Cpu Power" is sleeping :\ >>>> >>>> >>>> It appears freeswitch is only capable of using let's say "one cpu"/thread ?? >>>> Do you guys recommend simply starting more instances or redoing the IVR stuff. >>>> >>>> >>>> Hope you guys can help me out. >>>> >>>> Thanks >>>> António Teixeira >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>

---

...

...

>>>> FreeSWITCH-users mailing list >>>> FreeSWITCH-users@lists.freeswitch.org >>>>

http://lists.freeswitch.org/mailman/listinfo/freeswitch-users

...

>>>> UNSUBSCRIBE:

http://lists.freeswitch.org/mailman/options/freeswitch-users

...

>>>> http://www.freeswitch.org >>> >>> >>> -- >>> Ing. Christian Löschenkohl >>> Technische Leitung, Forschung& Entwicklung VoIP >>> >>> xpirio >>> Telekommunikation& Service GmbH >>> Lakeside B04 >>> 9020 Klagenfurt >>> Austria >>> >>> T +43 5 77 11 - 1000 >>> F +43 5 77 11 - 1002 >>> E christian.loeschenkohl@xpirio.com >>> >>>

---

...

...

>>> FreeSWITCH-users mailing list >>> FreeSWITCH-users@lists.freeswitch.org >>>

http://lists.freeswitch.org/mailman/listinfo/freeswitch-users

...

>>> UNSUBSCRIBE:

http://lists.freeswitch.org/mailman/options/freeswitch-users

...

>>> http://www.freeswitch.org >> >>

---

...

...

>> FreeSWITCH-users mailing list >> FreeSWITCH-users@lists.freeswitch.org >>

http://lists.freeswitch.org/mailman/listinfo/freeswitch-users

...

>> UNSUBSCRIBE:

http://lists.freeswitch.org/mailman/options/freeswitch-users

...

>> http://www.freeswitch.org > > > -- > Ing. Christian Löschenkohl > Technische Leitung, Forschung & Entwicklung VoIP > > xpirio > Telekommunikation & Service GmbH > Lakeside B04 > 9020 Klagenfurt > Austria > > T +43 5 77 11 - 1000 > F +43 5 77 11 - 1002 > E christian.loeschenkohl@xpirio.com > >

---

...

...

> FreeSWITCH-users mailing list > FreeSWITCH-users@lists.freeswitch.org >

http://lists.freeswitch.org/mailman/listinfo/freeswitch-users

...

> UNSUBSCRIBE:

http://lists.freeswitch.org/mailman/options/freeswitch-users

...

> http://www.freeswitch.org >

---

...

...

FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org

http://lists.freeswitch.org/mailman/listinfo/freeswitch-users

...

UNSUBSCRIBE:

http://lists.freeswitch.org/mailman/options/freeswitch-users

...

http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org

http://lists.freeswitch.org/mailman/listinfo/freeswitch-users

...

UNSUBSCRIBE:

http://lists.freeswitch.org/mailman/options/freeswitch-users

...

http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org

http://lists.freeswitch.org/mailman/listinfo/freeswitch-users

...

UNSUBSCRIBE:

http://lists.freeswitch.org/mailman/options/freeswitch-users

...

http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:

http://lists.freeswitch.org/mailman/options/freeswitch-users

...

http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:

http://lists.freeswitch.org/mailman/options/freeswitch-users

...

http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

Humm What about this one. http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_sched_hangup and / or there is also a possibility to hangup if you do not recveive any media (RTP) just be careful with Voice Activation. 2011/4/25 François Delawarde <fdelawarde@wirelessmundi.com>

Thanks Antonio, I'm already using that along with iptables rate limiting. It fits my needs but I need to run tests every time I install FS in a new hardware to find the optimal values.

It's good enough for me, but I was just wondering if there was anything more automatic like some timer that could drop the call if it takes too long to process.

It could also be useful for stalled DB connections or similar endless loops in some badly coded IVR applications.

François.

On Mon, 2011-04-25 at 10:05 +0100, Antonio Teixeira wrote:

...

Good Morning.

@ Steven, Thanks for the idea i will make a prototype in Python , and will send you guysthe performance data when i have it.

@ François

You probably want this. http://wiki.freeswitch.org/wiki/XML_Switch_Configuration

'sessions-per-second' - throttling mechanism, the switch will only create this many channels at most, per second.

2011/4/25 François Delawarde <fdelawarde@wirelessmundi.com> I also experienced a huge delay issue when attacked by mister "friendly-scanner". The machine was not overloaded and call setup was working well but with a 10-20 seconds delay. Note that the delay was only with SIP answers, and once RTP was setup the audio was perfect.

Following advices from http://wiki.freeswitch.org/wiki/QoS solved it in my case. Is there a mechanism in FS that could detect huge call setup delay and simply reject calls?

François.

On Sat, 2011-04-23 at 14:46 +0100, Steven Ayre wrote: > ESL would be best as you can offload the processing to another server > - potentially a load balanced cluster. > > Steve on iPhone > > On 23 Apr 2011, at 08:51, Antonio Teixeira <eagle.antonio@gmail.com> > wrote: > > > > > Hello Michael & The rest. > > > > What i'm trying to find is the solution with the highest performance > > for IVR Applications. And squeezing the last bit of performance out > > of freeswitch is a needed path specially on a industry that does > > second by second billing :P > > i'm going to do some performance testing with Lua , ESL And Mod Curl > > and of course python and measure some performance data and will post > > it later. > > > > A/T > > > > > > 2011/4/22 Michael Collins <msc@freeswitch.org> > > You can definitely use the event socket. Heck, you can even > > use Python if you want to. The dev team wrote ESL > > specifically for cases like these - where you want to > > control FS externally. ESL beats the pants off AGI scripts. > > It gives you complete control over the system. > > > > > > That all being said, you can do all sorts of stuff with Lua > > dialplan scripts. Check out chapter 7 of the FreeSWITCH book > > for some nice examples. Lua is lightweight and easy to > > learn. It's a good alternative for many cases. Check it > > out... > > > > > > -MC > > > > > > > > On Fri, Apr 22, 2011 at 12:39 PM, Antonio Teixeira > > <eagle.antonio@gmail.com> wrote: > > Well i totally agree with the Dev team decision , it > > would be impossible for a DEV team to "get it right" > > in all the distros that's why i started this post. > > > > But we also need to take into consideration that we > > are talking about IVR Processing , not > > auto-attendants or simply call pass trough. > > This means heavy use of TTS / ASR , Database Logic > > and Scripts , GetDigits and the works. > > > > I use python alot , but i think the mod_python is > > not the best tool for this job i admit that , that's > > why im currently looking for other solutions. > > I'm thinking in using mod_socket , but that scares > > me ( letś say bad experiences with Asterisk AGI) Or > > Mod Curl > > > > The main problem is that some IVR are extremely > > complex , like questionnaires , etc. > > > > It would be great if we could mod_event_zmq to > > control the calls <330.gif> > > > > Just to Sum it UP so far , so i can later add it to > > the wiki. > > > > Use Cent OS 64. > > Use tmpfs for all the databases. > > > > Thank you all for helping and Happy Eastern. > > António Teixeira > > > > > > > > > > > > > > 2011/4/22 Michael Collins <msc@freeswitch.org> > > FreeSWITCH runs well on many platforms. > > However, the devs are painfully aware that > > bleeding edge distros have bleeding edge gcc > > compilers and other interesting issues. That > > being said, CentOS 5.x is "stable" in that > > it's old and boring, therefore it has the > > least amount of drama. OTOH, some of our > > users have been having great success with > > Arch Linux (IRC:bougeyman) and FS, even > > though Arch uses very recent kernels. > > > > > > Bottom line: if you know what you're doing > > then you can probably run FS anywhere. If > > you don't know what you're doing then stick > > with CentOS 5.x or Debian Lenny until you > > do. (I run then both with zero issues, > > compiling latest git each day.) > > > > > > -MC > > > > > > > > On Fri, Apr 22, 2011 at 10:03 AM, > > curriegrad2004 <curriegrad2004@gmail.com> > > wrote: > > Freeswitch is targeted for CentOS > > 5.3, which in my opinion quite short > > sighted for the developers to do > > this. However with the limited size > > of developers and testers, I'm > > afraid there's not much platforms we > > can throughly test and actually say > > "okay, FS will run flawlessly on X > > distro" > > > > However you can always try messing > > with the CFLAG's mtune option and > > see what it produces for you... > > > > 2011/4/22 Christian Löschenkohl > > <christian.loeschenkohl@xpirio.com>: > > > > > hi > > > > > > if you refer to my e-mail > > > > > > yes, we do use tmpfs on both > > variants but > > > - delays occur with concurrent > > calls > 80-100 > > > - cps is limited to 5-10 on > > debian, with centos 30 cps and more > > are no problem at all > > > > > > also cpu load, stability and > > overall performace have been much > > better since using centos > > > > > > i just found out for me that > > debian works not as good for me as > > centos does. > > > btw. everywhere else debian is 1st > > choice (desktop, lamp, db etc.) > > > > > > br > > > > > > > > > On 2011-04-21 23:04, Jay Binks > > wrote: > > > > > >> I have no such problems on > > debian . > > >> > > >> I use debian 5 with 2.6.18 kernel > > which is what Is recommended > > >> > > >> Are you using tmpfs ?? > > >> > > >> Jay > > >> > > >> > > >> > > >> On 22/04/2011, at 3:26 AM, > > Christian > > Löschenkohl<christian.loeschenkohl@xpirio.com> wrote: > > >> > > >>> hi > > >>> > > >>> we did use debian too and had > > such performance issues (sip packet > > delays, low cps). > > >>> after using centos 64bit (as > > advised by the devs) all performance > > problems are gone. > > >>> > > >>> br > > >>> > > >>> On 2011-04-21 18:24, Antonio > > Teixeira wrote: > > >>> > > >>>> Hello List. > > >>>> > > >>>> I'm currently integrating an > > IVR in python together with > > freeswitch using mod_python and ESL > > and my life has been well until ... > > >>>> The flow of calls went over 80 > > simultaneous calls. > > >>>> Now freeswitch starts sending > > packets with huge delays ( even when > > establishing the call , mainly the > > 200 ) and firing up the IVR with > > tons of delay up to 20 seconds. > > >>>> > > >>>> So i searched the wiki forums > > and mailing list: > > >>>> > > >>>> Put freeswitch on a diet , > > trimmed modules.conf > > >>>> Played with the ulimit stuff. > > >>>> Played with the IVRS to reduce > > load to a minimum and i was able to > > squeeze more 5 calls of performance. > > >>>> > > >>>> The problem is : > > >>>> > > >>>> Top shows > > >>>> top - 16:14:33 up 35 days, > > 8:15, 3 users, load average: > > 1.92, 1.76, 1.78 > > >>>> Tasks: 133 total, 1 running, > > 132 sleeping, 0 stopped, 0 > > zombie > > >>>> Cpu(s): 1.4%us, 3.3%sy, 0.0% > > ni, 94.6%id, 0.0%wa, 0.3%hi, 0.5% > > si, 0.0%st > > >>>> Mem: 8193336k total, > > 1639156k used, 6554180k free, > > 177208k buffers > > >>>> Swap: 19534904k total, > > 0k used, 19534904k free, 1062272k > > cached > > >>>> > > >>>> PID USER PR NI VIRT > > RES SHR S %CPU %MEM TIME+ > > COMMAND > > >>>> 31361 yadayada 20 0 > > 716m 164m 9628 S 73 2.1 > > 155:17.85 freeswitch > > >>>> > > >>>> Freeswitch goes up to 150 % and > > puff there goes the MOS down to 0. > > >>>> > > >>>> > > >>>> Some basic System Info : > > >>>> Debian 6.0 ( i heard the > > timming module is affected by > > Debian , but if the CPU % gets lower > > than 95% everything will be more > > stable) > > >>>> Python 2.5 > > >>>> > > >>>> 2 x Intel(R) Xeon(R) CPU > > E5506 @ 2.13GHz > > >>>> 8 GB of Ram > > >>>> > > >>>> as you can see 94 % of the "Cpu > > Power" is sleeping :\ > > >>>> > > >>>> > > >>>> It appears freeswitch is only > > capable of using let's say "one > > cpu"/thread ?? > > >>>> Do you guys recommend simply > > starting more instances or redoing > > the IVR stuff. > > >>>> > > >>>> > > >>>> Hope you guys can help me out. > > >>>> > > >>>> Thanks > > >>>> António Teixeira > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > _______________________________________________ > > >>>> FreeSWITCH-users mailing list > > >>>> > > FreeSWITCH-users@lists.freeswitch.org > > >>>> > > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > > >>>> > > UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users > > >>>> http://www.freeswitch.org > > >>> > > >>> > > >>> -- > > >>> Ing. Christian Löschenkohl > > >>> Technische Leitung, Forschung& > > Entwicklung VoIP > > >>> > > >>> xpirio > > >>> Telekommunikation& Service GmbH > > >>> Lakeside B04 > > >>> 9020 Klagenfurt > > >>> Austria > > >>> > > >>> T +43 5 77 11 - 1000 > > >>> F +43 5 77 11 - 1002 > > >>> E > > christian.loeschenkohl@xpirio.com > > >>> > > >>> > > _______________________________________________ > > >>> FreeSWITCH-users mailing list > > >>> > > FreeSWITCH-users@lists.freeswitch.org > > >>> > > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > > >>> > > UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users > > >>> http://www.freeswitch.org > > >> > > >> > > _______________________________________________ > > >> FreeSWITCH-users mailing list > > >> > > FreeSWITCH-users@lists.freeswitch.org > > >> > > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > > >> > > UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users > > >> http://www.freeswitch.org > > > > > > > > > -- > > > Ing. Christian Löschenkohl > > > Technische Leitung, Forschung & > > Entwicklung VoIP > > > > > > xpirio > > > Telekommunikation & Service GmbH > > > Lakeside B04 > > > 9020 Klagenfurt > > > Austria > > > > > > T +43 5 77 11 - 1000 > > > F +43 5 77 11 - 1002 > > > E > > christian.loeschenkohl@xpirio.com > > > > > > > > _______________________________________________ > > > FreeSWITCH-users mailing list > > > > > FreeSWITCH-users@lists.freeswitch.org > > > > > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > > > > > UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users > > > http://www.freeswitch.org > > > > > > > _______________________________________________ > > FreeSWITCH-users mailing list > > FreeSWITCH-users@lists.freeswitch.org > > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > > UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users > > http://www.freeswitch.org > > > > > > > > > > _______________________________________________ > > FreeSWITCH-users mailing list > > FreeSWITCH-users@lists.freeswitch.org > > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > > UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users > > http://www.freeswitch.org > > > > > > > > > > _______________________________________________ > > FreeSWITCH-users mailing list > > FreeSWITCH-users@lists.freeswitch.org > > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > > UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users > > http://www.freeswitch.org > > > > > > > > > > _______________________________________________ > > FreeSWITCH-users mailing list > > FreeSWITCH-users@lists.freeswitch.org > > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > > UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users > > http://www.freeswitch.org > > > > > > > > _______________________________________________ > > FreeSWITCH-users mailing list > > FreeSWITCH-users@lists.freeswitch.org > > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > > UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users > > http://www.freeswitch.org > > > _______________________________________________ > FreeSWITCH-users mailing list > FreeSWITCH-users@lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users > http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

Just a little update for you guys. I have jumped from debian to centos did a full reinstall + Raid 1 + DB in Ram. And was able to get 78 Simult. Calls at only 10 % CPU so there is a huge difference so far from 120 % on debian :\. Call quality has improved , local lan call quality has rised , G729 Licenses working again thanks Brian West !!!. I will now start to deploy our IVRs using ESL to see if i can offload some of the load. Regards A/T 2011/4/27 Paul Cupis <paul@cupis.co.uk>

On 27/04/11 01:24, Ariel Monaco wrote:

...

We had high CPU utilization peaks in the past, which lead to some audio issues (clipping). We were using debian at that time, which was a customer-side requirement.

I'm not a kernel guru but I remember this had something to do with kernel timer cycles and the issue was address by adding "divider=10" or "divider=100" as a kernel's boot loader option.

Interesting. This kernel option is designed to reduce the valy of CONFIG_HZ at run=time, so if you have a 1000Hz kernel, setting divider=10 at boot time will effectively give you a 100Hz kernel.

This seems to fly in the face of other recommendations on this kernel setting!

Debian default kernel sets CONFIG_HZ=100 CentOS default kernel sets CONFIG_HZ=1000

Regards,

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

Raid 1 yes , but no DB in ram 2011/4/27 Avi Marcus <avi@avimarcus.net>

Did you have the Raid 1 and DB in ram on debian, too..? -Avi

On Wed, Apr 27, 2011 at 1:30 PM, Antonio Teixeira <eagle.antonio@gmail.com

...

wrote:

...

Just a little update for you guys.

I have jumped from debian to centos did a full reinstall + Raid 1 + DB in Ram.

And was able to get 78 Simult. Calls at only 10 % CPU so there is a huge difference so far from 120 % on debian :\. Call quality has improved , local lan call quality has rised , G729 Licenses working again thanks Brian West !!!.

I will now start to deploy our IVRs using ESL to see if i can offload some of the load.

Regards A/T

2011/4/27 Paul Cupis <paul@cupis.co.uk>

...

On 27/04/11 01:24, Ariel Monaco wrote:

...

We had high CPU utilization peaks in the past, which lead to some audio issues (clipping). We were using debian at that time, which was a customer-side requirement.

I'm not a kernel guru but I remember this had something to do with kernel timer cycles and the issue was address by adding "divider=10" or "divider=100" as a kernel's boot loader option.

Interesting. This kernel option is designed to reduce the valy of CONFIG_HZ at run=time, so if you have a 1000Hz kernel, setting divider=10 at boot time will effectively give you a 100Hz kernel.

This seems to fly in the face of other recommendations on this kernel setting!

Debian default kernel sets CONFIG_HZ=100 CentOS default kernel sets CONFIG_HZ=1000

Regards,

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

Yes a default installation of debian ( minimal/base ) also take into consideration this install was before that wiki warning regarding the divider of the kernel HZ thingy. 2011/4/27 François Delawarde <fdelawarde@wirelessmundi.com>

Did you use the default kernel in your debian setup?

François.

On Wed, 2011-04-27 at 10:30 +0000, Antonio Teixeira wrote:

...

Just a little update for you guys.

I have jumped from debian to centos did a full reinstall + Raid 1 + DB in Ram.

And was able to get 78 Simult. Calls at only 10 % CPU so there is a huge difference so far from 120 % on debian :\. Call quality has improved , local lan call quality has rised , G729 Licenses working again thanks Brian West !!!.

I will now start to deploy our IVRs using ESL to see if i can offload some of the load.

Regards A/T

2011/4/27 Paul Cupis <paul@cupis.co.uk> On 27/04/11 01:24, Ariel Monaco wrote: > We had high CPU utilization peaks in the past, which lead to some > audio issues (clipping). We were using debian at that time, which > was a customer-side requirement. > > I'm not a kernel guru but I remember this had something to do with > kernel timer cycles and the issue was address by adding "divider=10" > or "divider=100" as a kernel's boot loader option.

Interesting. This kernel option is designed to reduce the valy of CONFIG_HZ at run=time, so if you have a 1000Hz kernel, setting divider=10 at boot time will effectively give you a 100Hz kernel.

This seems to fly in the face of other recommendations on this kernel setting!

Debian default kernel sets CONFIG_HZ=100 CentOS default kernel sets CONFIG_HZ=1000

Regards,

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

for info I'm using the old Fedora10 64bits and everything is working fine with fq at 1000hz ----- Original Message ----- From: "Ariel Monaco" <arielmonaco@flylabs.com> To: "FreeSWITCH Users Help" <freeswitch-users@lists.freeswitch.org> Sent: Tuesday, April 26, 2011 8:24 PM Subject: Re: [Freeswitch-users] Tuning Up Freeswitch We had high CPU utilization peaks in the past, which lead to some audio issues (clipping). We were using debian at that time, which was a customer-side requirement. I'm not a kernel guru but I remember this had something to do with kernel timer cycles and the issue was address by adding "divider=10" or "divider=100" as a kernel's boot loader option. My 2 cents, Ariel On Apr 21, 2011, at 13:24 , Antonio Teixeira wrote:

Hello List.

I'm currently integrating an IVR in python together with freeswitch using mod_python and ESL and my life has been well until ... The flow of calls went over 80 simultaneous calls. Now freeswitch starts sending packets with huge delays ( even when establishing the call , mainly the 200 ) and firing up the IVR with tons of delay up to 20 seconds.

So i searched the wiki forums and mailing list:

Put freeswitch on a diet , trimmed modules.conf Played with the ulimit stuff. Played with the IVRS to reduce load to a minimum and i was able to squeeze more 5 calls of performance.

The problem is :

Top shows top - 16:14:33 up 35 days, 8:15, 3 users, load average: 1.92, 1.76, 1.78 Tasks: 133 total, 1 running, 132 sleeping, 0 stopped, 0 zombie Cpu(s): 1.4%us, 3.3%sy, 0.0%ni, 94.6%id, 0.0%wa, 0.3%hi, 0.5%si, 0.0%st Mem: 8193336k total, 1639156k used, 6554180k free, 177208k buffers Swap: 19534904k total, 0k used, 19534904k free, 1062272k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 31361 yadayada 20 0 716m 164m 9628 S 73 2.1 155:17.85 freeswitch

Freeswitch goes up to 150 % and puff there goes the MOS down to 0.

Some basic System Info : Debian 6.0 ( i heard the timming module is affected by Debian , but if the CPU % gets lower than 95% everything will be more stable) Python 2.5

2 x Intel(R) Xeon(R) CPU E5506 @ 2.13GHz 8 GB of Ram

as you can see 94 % of the "Cpu Power" is sleeping :\

It appears freeswitch is only capable of using let's say "one cpu"/thread ?? Do you guys recommend simply starting more instances or redoing the IVR stuff.

Hope you guys can help me out.

Thanks António Teixeira

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

Ariel Monaco – Systems Engineer Flylabs - Open Source Telecommunications and IT Consultants Address: Potosí 4456 C1199ACP - Buenos Aires - Argentina Web: http://flylabs.com E-Mail: arielmonaco@flylabs.com Tel. +54 (11) 4982-2689, +1 (315) 688-7333 _______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

Sounds kind of strange, that means: we should limit the simultaneous call per profile what about users, by default they do to 'Internal" profile, so to avoid bottleneck, several profiles should be used for serving large amount of users? 2011/5/24 Antonio Teixeira <eagle.antonio@gmail.com>:

Sorry To Revive A Old Thread.

But this could be interesting for some :

Problem : I started to get some signaling problems with some calls :

The SIP trunk was passing me 180 Ringing but the local station was not ringing , after a wire shark sniff i noticed that packets were coming out of order. Before calling our ISP , i used wire shark on the FS Public Interface , and the packets were coming in the correct order but FS would take up to 5 seconds to route them into the private network and would mix the signaling. So debug started , there was lots of CPU + Memory , IO was not a problem , network was also fine with 0 packet loss .

So i turned into FS , i noticed this happened on a specific call volume , after reading and reading i noticed a line in the wiki stating that libsofia profile is single threaded .

Solution :

Start Another Profile on a different port Ex:  5081 and route your calls trough that profile i noticed an improvement right away.

originate sofia/2_profile/XXXXXX@mygatewayip

Now i'm using profiles to load balance calls inside FS.

P.S - I know this can be pretty obvious for some but some of us are still new to FS so i hope this can help someone out :D. P.S2 - Also if a veteran thinks this is the wrong approach please respond so we can all improve.

Regards Antonio teixeira

2011/4/27 Madovsky <infos@madovsky.org>

...

for info I'm using the old Fedora10 64bits and everything is working fine with fq at 1000hz

----- Original Message ----- From: "Ariel Monaco" <arielmonaco@flylabs.com> To: "FreeSWITCH Users Help" <freeswitch-users@lists.freeswitch.org> Sent: Tuesday, April 26, 2011 8:24 PM Subject: Re: [Freeswitch-users] Tuning Up Freeswitch

We had high CPU utilization peaks in the past, which lead to some audio issues (clipping). We were using debian at that time, which was a customer-side requirement.

I'm not a kernel guru but I remember this had something to do with kernel timer cycles and the issue was address by adding "divider=10" or "divider=100" as a kernel's boot loader option.

My 2 cents, Ariel

On Apr 21, 2011, at 13:24 , Antonio Teixeira wrote:

...

Hello List.

I'm currently integrating an IVR in python together with freeswitch using mod_python and ESL and my life has been well until ... The flow of calls went over 80 simultaneous calls. Now freeswitch starts sending packets with huge delays ( even when establishing the call , mainly the 200 ) and firing up the IVR with tons of delay up to 20 seconds.

So i searched the wiki forums and mailing list:

Put freeswitch on a diet , trimmed modules.conf Played with the ulimit stuff. Played with the IVRS to reduce load to a minimum and i was able to squeeze more 5 calls of performance.

The problem is :

Top shows top - 16:14:33 up 35 days,  8:15,  3 users,  load average: 1.92, 1.76, 1.78 Tasks: 133 total,   1 running, 132 sleeping,   0 stopped,   0 zombie Cpu(s):  1.4%us,  3.3%sy,  0.0%ni, 94.6%id,  0.0%wa,  0.3%hi,  0.5%si, 0.0%st Mem:   8193336k total,  1639156k used,  6554180k free,   177208k buffers Swap: 19534904k total,        0k used, 19534904k free,  1062272k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND 31361 yadayada      20   0  716m 164m 9628 S   73  2.1 155:17.85 freeswitch

Freeswitch goes up to 150 % and puff there goes the MOS down to 0.

Some basic System Info : Debian 6.0 ( i heard the timming module is affected by Debian , but if the CPU % gets lower than 95% everything will be more stable) Python 2.5

2 x Intel(R) Xeon(R) CPU           E5506  @ 2.13GHz 8 GB of Ram

as you can see 94 % of the "Cpu Power" is sleeping :\

It appears freeswitch is only capable of using let's say "one cpu"/thread ?? Do you guys recommend simply starting more instances or redoing the IVR stuff.

Hope you guys can help me out.

Thanks António Teixeira

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

Ariel Monaco – Systems Engineer Flylabs - Open Source Telecommunications and  IT Consultants

Address: Potosí 4456 C1199ACP - Buenos Aires - Argentina Web: http://flylabs.com E-Mail: arielmonaco@flylabs.com Tel. +54 (11) 4982-2689, +1 (315) 688-7333

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

the only real improvment was to move your DB to tmpfs ... the rest ( if 64bit) makes really small difference from distro to distro.. also set your ulimits accordingly! cheers. 2011/5/24 Juan Antonio Ibañez Santorum <juanito1982@gmail.com>

How do you make that load balancing between profiles?

2011/5/24 Antonio Teixeira <eagle.antonio@gmail.com>

...

Sorry To Revive A Old Thread.

But this could be interesting for some :

Problem : I started to get some signaling problems with some calls :

The SIP trunk was passing me 180 Ringing but the local station was not ringing , after a wire shark sniff i noticed that packets were coming out of order. Before calling our ISP , i used wire shark on the FS Public Interface , and the packets were coming in the correct order but FS would take up to 5 seconds to route them into the private network and would mix the signaling. So debug started , there was lots of CPU + Memory , IO was not a problem , network was also fine with 0 packet loss .

So i turned into FS , i noticed this happened on a specific call volume , after reading and reading i noticed a line in the wiki stating that libsofia profile is single threaded .

Solution :

Start Another Profile on a different port Ex: 5081 and route your calls trough that profile i noticed an improvement right away.

originate sofia/2_profile/XXXXXX@mygatewayip

Now i'm using profiles to load balance calls inside FS.

P.S - I know this can be pretty obvious for some but some of us are still new to FS so i hope this can help someone out :D. P.S2 - Also if a veteran thinks this is the wrong approach please respond so we can all improve.

Regards Antonio teixeira

2011/4/27 Madovsky <infos@madovsky.org>

...

for info I'm using the old Fedora10 64bits and everything is working fine with fq at 1000hz

----- Original Message ----- From: "Ariel Monaco" <arielmonaco@flylabs.com> To: "FreeSWITCH Users Help" <freeswitch-users@lists.freeswitch.org> Sent: Tuesday, April 26, 2011 8:24 PM Subject: Re: [Freeswitch-users] Tuning Up Freeswitch

We had high CPU utilization peaks in the past, which lead to some audio issues (clipping). We were using debian at that time, which was a customer-side requirement.

I'm not a kernel guru but I remember this had something to do with kernel timer cycles and the issue was address by adding "divider=10" or "divider=100" as a kernel's boot loader option.

My 2 cents, Ariel

On Apr 21, 2011, at 13:24 , Antonio Teixeira wrote:

...

Hello List.

I'm currently integrating an IVR in python together with freeswitch using mod_python and ESL and my life has been well until ... The flow of calls went over 80 simultaneous calls. Now freeswitch starts sending packets with huge delays ( even when establishing the call , mainly the 200 ) and firing up the IVR with tons of delay up to 20 seconds.

So i searched the wiki forums and mailing list:

Put freeswitch on a diet , trimmed modules.conf Played with the ulimit stuff. Played with the IVRS to reduce load to a minimum and i was able to squeeze more 5 calls of performance.

The problem is :

Top shows top - 16:14:33 up 35 days, 8:15, 3 users, load average: 1.92, 1.76, 1.78 Tasks: 133 total, 1 running, 132 sleeping, 0 stopped, 0 zombie Cpu(s): 1.4%us, 3.3%sy, 0.0%ni, 94.6%id, 0.0%wa, 0.3%hi, 0.5%si, 0.0%st Mem: 8193336k total, 1639156k used, 6554180k free, 177208k buffers Swap: 19534904k total, 0k used, 19534904k free, 1062272k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 31361 yadayada 20 0 716m 164m 9628 S 73 2.1 155:17.85 freeswitch

Freeswitch goes up to 150 % and puff there goes the MOS down to 0.

Some basic System Info : Debian 6.0 ( i heard the timming module is affected by Debian , but if the CPU % gets lower than 95% everything will be more stable) Python 2.5

2 x Intel(R) Xeon(R) CPU E5506 @ 2.13GHz 8 GB of Ram

as you can see 94 % of the "Cpu Power" is sleeping :\

It appears freeswitch is only capable of using let's say "one cpu"/thread ?? Do you guys recommend simply starting more instances or redoing the IVR stuff.

Hope you guys can help me out.

Thanks António Teixeira

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

Ariel Monaco – Systems Engineer Flylabs - Open Source Telecommunications and IT Consultants

Address: Potosí 4456 C1199ACP - Buenos Aires - Argentina Web: http://flylabs.com E-Mail: arielmonaco@flylabs.com Tel. +54 (11) 4982-2689, +1 (315) 688-7333

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

moving your SQLlite DB to tempFS is the biggest single change you can have with FS. that alone would account for the massive increase in calls you were able to achieve. On Tue, May 24, 2011 at 9:57 PM, Anton VG <anton.vazir@gmail.com> wrote:

do you mean sqlite?

2011/5/24 Tihomir Culjaga <tculjaga@gmail.com>:

...

the only real improvment was to move your DB to tmpfs ... the rest ( if 64bit) makes really small difference from distro to distro..

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

-- Sincerely Jay

Regarding the SIgnaling Problem , the DB was already on tmpfs and you may have read that this was not an I/O problem. To load Blance a call is simple in our use case. First understand we use auto-dialers so alot happens in the backend , the rest we send a originate command so simply change the profile used imagine : originate sofia/external1_profile/22222222@111.11.11.11 IVR XML The dialer simply changes originate sofia/external1_profile/22222222@111.11.11.11 IVR XML originate sofia/external2_profile/22222222@111.11.11.11 IVR XML originate sofia/external3_profile/22222222@111.11.11.11 IVR XML originate sofia/external4_profile/22222222@111.11.11.11 IVR XML We use INB ESL. Now if you want to use "softphones" i think you can use mod_limit and the XML dialplan to create a realtime version of this. Notes : Keep in mind that i do not know if this is the correct way to handle this situation but we have it deployed this way and as i was able to increase the call volume by a factor of 2 while at the same time increasing quality and decreasing the signaling issues. At the expense of RAM more RAM = Profiles. 2011/5/24 jay binks <jaybinks@gmail.com>

moving your SQLlite DB to tempFS is the biggest single change you can have with FS. that alone would account for the massive increase in calls you were able to achieve.

On Tue, May 24, 2011 at 9:57 PM, Anton VG <anton.vazir@gmail.com> wrote:

...

do you mean sqlite?

2011/5/24 Tihomir Culjaga <tculjaga@gmail.com>:

...

the only real improvment was to move your DB to tmpfs ... the rest ( if 64bit) makes really small difference from distro to distro..

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

-- Sincerely

Jay

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

Well this is a 2 X E5506 With 8 GB of Ram. The Main Problem is that we use tons of DTMF + TTS + Dialplan Logic and as you say Anthony this causes an impact on the total Supported Calls. I'm building a new IVR server that we can deploy on another server so we can ease the pain that mod_python is causing on the CPU. TOP Shows AVG idle CPU at 93 % Anyway for every performance increment i find i will post it here. Thanks Anthony for your input i think i got your point , I'm assuming an SBC with media bypass would handle a lot more calls per profile but as you may have guessed my objective is not SipTrunking but a high layer of service. Anyway thanks alot. Regards Antonio Teixeira 2011/5/24 Anthony Minessale <anthony.minessale@gmail.com>

Anything you find useful to get more calls is subjective to the power of the box. If sofia starts behaving badly, it indicates a maximum resource consumption. More profiles of course help with concurrency.

So I could have a box where I could do 5000 calls before another profile would help and someone else could get benefits of multiple profiles at 100 calls.

You have 2 choices: 1) Search for ways to squeeze more calls out of a bad box like we used to do with config.sys in DOS 2) Use the money you saved by getting a free carrier grade switch platform and buy a halfway decent box.

On Tue, May 24, 2011 at 7:48 AM, Antonio Teixeira <eagle.antonio@gmail.com> wrote:

...

Regarding the SIgnaling Problem , the DB was already on tmpfs and you may have read that this was not an I/O problem.

To load Blance a call is simple in our use case.

First understand we use auto-dialers so alot happens in the backend , the rest we send a originate command so simply change the profile used imagine :

originate sofia/external1_profile/22222222@111.11.11.11 IVR XML

The dialer simply changes originate sofia/external1_profile/22222222@111.11.11.11 IVR XML originate sofia/external2_profile/22222222@111.11.11.11 IVR XML originate sofia/external3_profile/22222222@111.11.11.11 IVR XML originate sofia/external4_profile/22222222@111.11.11.11 IVR XML

We use INB ESL.

Now if you want to use "softphones" i think you can use mod_limit and the XML dialplan to create a realtime version of this.

Notes :

Keep in mind that i do not know if this is the correct way to handle this situation but we have it deployed this way and as i was able to increase the call volume by a factor of 2 while at the same time increasing quality and decreasing the signaling issues. At the expense of RAM more RAM = Profiles.

2011/5/24 jay binks <jaybinks@gmail.com>

...

moving your SQLlite DB to tempFS is the biggest single change you can

have

...

with FS. that alone would account for the massive increase in calls you were able to achieve.

On Tue, May 24, 2011 at 9:57 PM, Anton VG <anton.vazir@gmail.com> wrote:

...

do you mean sqlite?

2011/5/24 Tihomir Culjaga <tculjaga@gmail.com>:

...

the only real improvment was to move your DB to tmpfs ... the rest (

if

...

...

64bit) makes really small difference from distro to distro..

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

-- Sincerely

Jay

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

-- Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900

_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org