Re: [Freeswitch-users] Load test - performance not even matching Asterisk
Resolved: I have made further tests, and my final conclusion is that the previous stated test results were screwed by the application 'gentones'. This application does in some cases send more rtp than expected. If I used: <action application="gentones" data="%(5,0,300)"/> <action application="gentones" data="%(5,0,300)"/> <action application="gentones" data="%(60000,0,300)"/> the expected rtp of 8600 kB/s was transmitted. If I used <action application="gentones" data="%(60000,0,300)"/> <action application="gentones" data="%(5,0,300)"/> <action application="gentones" data="%(5,0,300)"/>. the rtp was 34600 kB/s, and the memory is heavily consumed. The only difference being the sequence of the gentones commands. I don't know if this is the expected behaviour of 'gentones' or not, but it certainly screwed up the results previously posted. /Jon
%(60000,0,300) means to generate a 60 second long 300hz tone %(5,0,300) means a 5 ms long 300hz tone if you are just trying to send a tone you are better off with <action application="gentones" data="%(1000,0,300)|60"/> which only generates 1 second of audio then buffers and loops it via the application rather than allocating enough room for 60 seconds of signed linear audio and generating the whole 60 seconds into memory for no reason vs 1 second sample looped 60 times. No matter what you do it will not effect the bandwidth used, it's a factor of what codec you are using. On Mon, Oct 6, 2008 at 4:15 AM, Jon Bruel <jbr@consiglia.dk> wrote:
Resolved: I have made further tests, and my final conclusion is that the previous stated test results were screwed by the application 'gentones'. This application does in some cases send more rtp than expected. If I used: <action application="gentones" data="%(5,0,300)"/> <action application="gentones" data="%(5,0,300)"/> <action application="gentones" data="%(60000,0,300)"/> the expected rtp of 8600 kB/s was transmitted. If I used <action application="gentones" data="%(60000,0,300)"/> <action application="gentones" data="%(5,0,300)"/> <action application="gentones" data="%(5,0,300)"/>. the rtp was 34600 kB/s, and the memory is heavily consumed. The only difference being the sequence of the gentones commands. I don't know if this is the expected behaviour of 'gentones' or not, but it certainly screwed up the results previously posted. /Jon
_______________________________________________ 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/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
Going back a step, to where Jon was seeing more packets than there should have been, I've just encountered a similar issue having upgraded to the latest, from what was probably a fairly old release - months old, rather than weeks. I've got two FS boxes (let's call them FS1 and FS2), each of which are plumbed in to carrier C. There's an IVR service running on FS1; FS2 bridges any calls which it gets for said IVR over to FS1. What I've just had is: - calls from C to FS1 directly work fine; - calls from C to FS2, thence to FS1 were silent. Looking at a capture from FS2, everything looks OK except the RTP between FS1 and FS2. On answer, there's a prompt played. What I see is three packets in a lump from FS1, then four packets sent back from FS2 to FS1, four packets in a lump from FS1, then five going back from FS2 to FS1, and so on. The lumps are 20ms apart (codec is G711 with 20ms packets) - what seems to be happening is that FS2 sends FS1 back the packets received from it unchanged plus an extra packet which has arrived from C in the meantime. FS2 ought to be sending these packets to C instead; it sends C nothing. I've made the problem go away by commenting out the bit in switch_rtp.c which auto-adjusts addresses (around line 1280.) All of the machines have public IPs; there's not a NAT in sight. I'll have a further look in the morning. --Dave
%(60000,0,300) means to generate a 60 second long 300hz tone %(5,0,300) means a 5 ms long 300hz tone
if you are just trying to send a tone you are better off with <action application="gentones" data="%(1000,0,300)|60"/>
which only generates 1 second of audio then buffers and loops it via the application rather than allocating enough room for 60 seconds of signed linear audio and generating the whole 60 seconds into memory for no reason vs 1 second sample looped 60 times.
No matter what you do it will not effect the bandwidth used, it's a factor of what codec you are using.
On Mon, Oct 6, 2008 at 4:15 AM, Jon Bruel <jbr@consiglia.dk> wrote: Resolved: I have made further tests, and my final conclusion is that the previous stated test results were screwed by the application 'gentones'. This application does in some cases send more rtp than expected. If I used: <action application="gentones" data="%(5,0,300)"/> <action application="gentones" data="%(5,0,300)"/> <action application="gentones" data="%(60000,0,300)"/> the expected rtp of 8600 kB/s was transmitted. If I used <action application="gentones" data="%(60000,0,300)"/> <action application="gentones" data="%(5,0,300)"/> <action application="gentones" data="%(5,0,300)"/>. the rtp was 34600 kB/s, and the memory is heavily consumed. The only difference being the sequence of the gentones commands. I don't know if this is the expected behaviour of 'gentones' or not, but it certainly screwed up the results previously posted. /Jon
_______________________________________________ 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/
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 iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org pstn:213-799-1400 _______________________________________________ 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
one tip is don't use -rtp_echo it sends 10 times the traffic back the other direction. /b On Oct 6, 2008, at 9:25 PM, David Knell wrote:
Going back a step, to where Jon was seeing more packets than there should have been, I've just encountered a similar issue having upgraded to the latest, from what was probably a fairly old release - months old, rather than weeks.
I've got two FS boxes (let's call them FS1 and FS2), each of which are plumbed in to carrier C. There's an IVR service running on FS1; FS2 bridges any calls which it gets for said IVR over to FS1. What I've just had is: - calls from C to FS1 directly work fine; - calls from C to FS2, thence to FS1 were silent. Looking at a capture from FS2, everything looks OK except the RTP between FS1 and FS2. On answer, there's a prompt played. What I see is three packets in a lump from FS1, then four packets sent back from FS2 to FS1, four packets in a lump from FS1, then five going back from FS2 to FS1, and so on.
The lumps are 20ms apart (codec is G711 with 20ms packets) - what seems to be happening is that FS2 sends FS1 back the packets received from it unchanged plus an extra packet which has arrived from C in the meantime.
FS2 ought to be sending these packets to C instead; it sends C nothing.
I've made the problem go away by commenting out the bit in switch_rtp.c which auto-adjusts addresses (around line 1280.)
All of the machines have public IPs; there's not a NAT in sight.
I'll have a further look in the morning.
--Dave
%(60000,0,300) means to generate a 60 second long 300hz tone %(5,0,300) means a 5 ms long 300hz tone
if you are just trying to send a tone you are better off with <action application="gentones" data="%(1000,0,300)|60"/>
which only generates 1 second of audio then buffers and loops it via the application rather than allocating enough room for 60 seconds of signed linear audio and generating the whole 60 seconds into memory for no reason vs 1 second sample looped 60 times.
No matter what you do it will not effect the bandwidth used, it's a factor of what codec you are using.
On Mon, Oct 6, 2008 at 4:15 AM, Jon Bruel <jbr@consiglia.dk> wrote: Resolved: I have made further tests, and my final conclusion is that the previous stated test results were screwed by the application 'gentones'. This application does in some cases send more rtp than expected. If I used: <action application="gentones" data="%(5,0,300)"/> <action application="gentones" data="%(5,0,300)"/> <action application="gentones" data="%(60000,0,300)"/> the expected rtp of 8600 kB/s was transmitted. If I used <action application="gentones" data="%(60000,0,300)"/> <action application="gentones" data="%(5,0,300)"/> <action application="gentones" data="%(5,0,300)"/>. the rtp was 34600 kB/s, and the memory is heavily consumed. The only difference being the sequence of the gentones commands. I don't know if this is the expected behaviour of 'gentones' or not, but it certainly screwed up the results previously posted. /Jon
_______________________________________________ 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/
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 iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org pstn:213-799-1400 _______________________________________________ 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
are you doing anything with bypass_media? We had another guy with something similar and we have not been able to nail it down besides he was doing a media call that shifted to bypass_media mode. If you have a situation where it happens every time a pcap and or FS console on debug of it happening would be nice. It seems odd that the auto adjust code is being triggered considering the design says that if the leg from FS1 -> C gets a packet from some other ip than that of C that it adjusts to that. So it would appear that somehow one of the packets from FS2 to FS1 ends up being picked up by the rtp socket that was meant for the FS1->C leg. (maybe a race in the port allocator giving both legs the same rtp port or something funny?) say your phone is A A -> FS1 (recv port 1000) FS1->FS2 (recv port 1002) FS2->C (recv port 1004) either port 1004 is somehow getting the packet meant for 1002 which would make no sense or somewhere in here both boxes picked the same port or the packet is somehow multicasting to both ports which would make no sense either. I would like to figure it out though if you could provide the details including the dp and all the attrs you set etc. BTW, you can turn off RTP auto ADJ both with a channel varable and a profile param (i forgot the name but it's on the wiki) On Mon, Oct 6, 2008 at 9:25 PM, David Knell <dave@3c.co.uk> wrote:
Going back a step, to where Jon was seeing more packets than thereshould have been, I've just encountered a similar issue having upgraded to the latest, from what was probably a fairly old release - months old, rather than weeks.
I've got two FS boxes (let's call them FS1 and FS2), each of which are plumbed in to carrier C. There's an IVR service running on FS1; FS2 bridges any calls which it gets for said IVR over to FS1. What I've just had is: - calls from C to FS1 directly work fine; - calls from C to FS2, thence to FS1 were silent. Looking at a capture from FS2, everything looks OK except the RTP between FS1 and FS2. On answer, there's a prompt played. What I see is three packets in a lump from FS1, then four packets sent back from FS2 to FS1, four packets in a lump from FS1, then five going back from FS2 to FS1, and so on.
The lumps are 20ms apart (codec is G711 with 20ms packets) - what seems to be happening is that FS2 sends FS1 back the packets received from it unchanged plus an extra packet which has arrived from C in the meantime.
FS2 ought to be sending these packets to C instead; it sends C nothing.
I've made the problem go away by commenting out the bit in switch_rtp.c which auto-adjusts addresses (around line 1280.)
All of the machines have public IPs; there's not a NAT in sight.
I'll have a further look in the morning.
--Dave
%(60000,0,300) means to generate a 60 second long 300hz tone %(5,0,300) means a 5 ms long 300hz tone
if you are just trying to send a tone you are better off with <action application="gentones" data="%(1000,0,300)|60"/>
which only generates 1 second of audio then buffers and loops it via the application rather than allocating enough room for 60 seconds of signed linear audio and generating the whole 60 seconds into memory for no reason vs 1 second sample looped 60 times.
No matter what you do it will not effect the bandwidth used, it's a factor of what codec you are using.
On Mon, Oct 6, 2008 at 4:15 AM, Jon Bruel <jbr@consiglia.dk> wrote:
Resolved: I have made further tests, and my final conclusion is that the previous stated test results were screwed by the application 'gentones'. This application does in some cases send more rtp than expected. If I used: <action application="gentones" data="%(5,0,300)"/> <action application="gentones" data="%(5,0,300)"/> <action application="gentones" data="%(60000,0,300)"/> the expected rtp of 8600 kB/s was transmitted. If I used <action application="gentones" data="%(60000,0,300)"/> <action application="gentones" data="%(5,0,300)"/> <action application="gentones" data="%(5,0,300)"/>. the rtp was 34600 kB/s, and the memory is heavily consumed. The only difference being the sequence of the gentones commands. I don't know if this is the expected behaviour of 'gentones' or not, but it certainly screwed up the results previously posted. /Jon
_______________________________________________ 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/
AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400 _______________________________________________ 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/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
This is now fixed in trunk: http://fisheye.freeswitch.org/changelog/FreeSWITCH/?cs=9917 Mike On Oct 6, 2008, at 10:25 PM, David Knell wrote:
Going back a step, to where Jon was seeing more packets than there should have been, I've just encountered a similar issue having upgraded to the latest, from what was probably a fairly old release - months old, rather than weeks.
I've got two FS boxes (let's call them FS1 and FS2), each of which are plumbed in to carrier C. There's an IVR service running on FS1; FS2 bridges any calls which it gets for said IVR over to FS1. What I've just had is: - calls from C to FS1 directly work fine; - calls from C to FS2, thence to FS1 were silent. Looking at a capture from FS2, everything looks OK except the RTP between FS1 and FS2. On answer, there's a prompt played. What I see is three packets in a lump from FS1, then four packets sent back from FS2 to FS1, four packets in a lump from FS1, then five going back from FS2 to FS1, and so on.
The lumps are 20ms apart (codec is G711 with 20ms packets) - what seems to be happening is that FS2 sends FS1 back the packets received from it unchanged plus an extra packet which has arrived from C in the meantime.
FS2 ought to be sending these packets to C instead; it sends C nothing.
I've made the problem go away by commenting out the bit in switch_rtp.c which auto-adjusts addresses (around line 1280.)
All of the machines have public IPs; there's not a NAT in sight.
I'll have a further look in the morning.
--Dave
Jon, We would appreciate it if you post all your testing scripts ,with results. And maybe you can even give us 5 minutes of your time and create a wiki page: "Load testing" This way the next person who's trying to reproduce the results and for all the unbelievers, will have an easy answer. Best Regards, Joseph
participants (6)
-
Anthony Minessale
-
Brian West
-
David Knell
-
Jon Bruel
-
Joseph Khoury
-
Michael Jerris