- FreeSWITCH-dev - FreeSWITCH Mailing Lists

mod_fifo.c question re: fifo count values
by Michael Collins 29 Sep '11

29 Sep '11

I was curious about this code snippet which appears in mod_fifo.c near line 3775 and again near line 3786: len = node_caller_count(node); switch_mutex_lock(node->update_mutex); stream->write_function(stream, "%s:%d:%d:%d\n", argv[1], node->consumer_count, node_caller_count(node), len); switch_mutex_unlock(node->update_mutex); I was curious: what's the difference in the stream->write between node_caller_count(node) and len? Under what circumstances would they be different? (I'm assuming the locking of the mutex after setting the value of len may have something to do with it...) Thanks, MC

2 1

FreeSWITCH Conference Call Today
by Michael Collins 28 Sep '11

28 Sep '11

Hello folks! We have a few items to discuss today. Here's the agenda: http://wiki.freeswitch.org/wiki/FS_weekly_2011_09_28 We have a few updates to share with everyone and we also would like to hear from you if you have been using mod_sms that just came out last week. Talk to you soon, Michael

1 0

Re: [Freeswitch-dev] MTU setting and application buffer size
by Juraj Fabo 28 Sep '11

28 Sep '11

Thank you for your answers. > ---------- Forwarded message ---------- > From: Moises Silva <moises.silva(a)gmail.com> > To: freeswitch-dev(a)lists.freeswitch.org > Date: Thu, 22 Sep 2011 16:05:06 -0400 > Subject: Re: [Freeswitch-dev] MTU setting and application buffer size > On Mon, Sep 19, 2011 at 12:30 PM, Juraj Fabo <juraj.fabo(a)gmail.com> wrote: >> Target application is reading/writing from/to another network stack >> A-law data with 20ms frame length. >> >> With default MTU settings (80) I am experiencing latency which I >> consider too high, it is about 400ms from targetApp to loopback and >> back to targetApp. > > There is something wrong with your app. The MTU in wanpipeX.conf is > meant to control the transfer size between the driver and the card, > not between the user space app and the driver. In general, higher MTU > means lower interrupt load. The lowest value is probably 8, which is > used for applications working in DAHDI-mode, where one interrupt is > received every millisecond and 8 bytes are transferred from the driver > to the hardware and viceversa. > >> I think I missed some point about proper setting of MTU and consequences. >> Decreasing the MTU configuration setting in the >> /etc/wanpipe/wanpipe1.conf from default value 80 to e.g 40 or 16 leads >> to desired lower latency, however, the data the targetApp is reading >> are often corrupted with many gaps. > > 80 means a hardware interrupt is received every 10ms with 80 bytes per > time slot. This is the recommended mode. A value of 40 will increase > interrupt load and not necesarily reduce your latency, you must reduce > the "user period", which is how often the driver will deliver > media/data to the user application. This is done using > sangoma_tdm_set_usr_period(). > >> Please, what is the proper way of setting MTU? >> I assume I have to set the same MTU per wXg1 sections in >> /etc/wanpipe/wanpipeX.conf files on both servers, since the serverA >> card is providing a clock for server B cards. >> Is it necessary to change the value of codec_ms in the >> /usr/local/freetdm/conf/wanpipe.conf ? > > The codec_ms is used to call sangoma_tdm_set_usr_period(). This is how > often the driver will deliver data to the user application (for > example, waking it up from select()). > >> I also noticed following behaviour of ifconfig: >> a. MTU set to 40 or higher in section w1g1 in wanpipe1.conf >> also all other spans of the card which has the w1g1 (so w2g1 for >> the dualspan and w2g1, w3g1,w4g1 for quad card) will be displayed in >> ifconfig output with MTU: 40 >> >> b. MTU set to 80 or higher (e.g. 160) in section w1g1 in wanpipe1.conf >> ifconfig will display MTU:80 also for higher values > > Some MTU values are disallowed, you would have to check which ones in > the driver, I don't recall. You can't use any value, as this values > are directly related with the capabilities of the hardware (some > cards, like analog cards, may only accept MTU of 8 for example). > I did set of latency / delay measurements in reduced testenvironment. Single server, single quad card with interconnected spans 1 and 2, testapplication is doing dump of read and written data on both call ends to binary files in the single thread. Please, have a look at the results with various parameters used: mtu:80 txqueue_size=1 rxqueue_size=1 one-direction delay=60ms round-trip delay=120ms mtu:80 txqueue_size=2 rxqueue_size=2 one-direction delay=80ms round-trip delay=160ms mtu:80 txqueue_size=10 rxqueue_size=10 one-direction delay=240ms round-trip delay=480ms mtu:40 txqueue_size=1 rxqueue_size=1 one-direction delay=40ms round-trip delay=80ms mtu:40 txqueue_size=2 rxqueue_size=2 one-direction delay=60ms round-trip delay=120ms mtu:40 txqueue_size=5 rxqueue_size=5 one-direction delay=120ms round-trip delay=240ms mtu:16 txqueue_size=1 rxqueue_size=1 one-direction delay=30ms round-trip delay=60ms mtu:8 txqueue_size=1 rxqueue_size=1 one-direction delay=25ms round-trip delay=50ms mtu:8 txqueue_size=10 rxqueue_size=10 one-direction delay=205ms round-trip delay=410ms The result from these tests is that the rxqueue_size is affecting the delay and no matter what is the MTU chunk size, increasing the rxqueue_size by one will increase the one-direction delay by 20ms. I also realized, that assymetric setting of tx/rx queue size can be used: e.g. tx_q_s=1 rx_q_s=10 to reduce the delay. Comment in the wanpipe.conf says: ; size of the driver queue of elements of MTU size ; typical case is 10 elements of 80 bytes each (10ms of ulaw/alaw) ; don't mess with this if you don't know what you're doing but I had not seen 80 bytes per element in the logs. With enabled DEBUG_TDMAPI following can be seen: Sep 27 20:02:34 v184 kernel: [2806213.900348] wanpipe1: Configuring Interface: w1g1 (log supress) Sep 27 20:02:34 v184 kernel: [2806213.900355] wanpipe1: Active Ch Map :0x00000004 Sep 27 20:02:34 v184 kernel: [2806213.900357] wanpipe1: First TSlot :2 Sep 27 20:02:34 v184 kernel: [2806213.900366] w1g1: TDM API ACTIVE CH 0x00000004 CHAN=2 Sep 27 20:02:34 v184 kernel: [2806213.900368] w1g1: TDM API ACTIVE CH 0x00000004 SPAN=1 CHAN=2 Sep 27 20:02:34 v184 kernel: [2806213.900370] w1g1: SPAN=1, CHAN=2 Chunk=80 Period=10 Mtu=80 Sep 27 20:02:34 v184 kernel: [2806213.900371] w1g1: conf->mtu=0 Sep 27 20:02:34 v184 kernel: [2806213.900372] w1g1: tdm_api_chunk=80, tdm_api_period=10 Sep 27 20:02:34 v184 kernel: [2806213.900374] wanpipe1: Chunk=160, Period=20, MTU=160 Sep 27 20:02:34 v184 kernel: [2806213.900398] wanpipe_tdm_api_reg(): usr_period: 20, hw_mtu_mru: 8 Sep 27 20:02:34 v184 kernel: [2806213.900400] wanpipe1: Configuring TDM API NAME=wanpipe1_if2 Qlen=5 TS=1 MTU=224 Here I found interesting these 2lines: Sep 27 20:02:34 v184 kernel: [2806213.900374] wanpipe1: Chunk=160, Period=20, MTU=160 Sep 27 20:02:34 v184 kernel: [2806213.900398] wanpipe_tdm_api_reg(): usr_period: 20, hw_mtu_mru: 8 which are result of the aft_core_prot.c 721 if (chan->wp_tdm_api_dev->cfg.usr_mtu_mru < 160) { 722 chan->tdm_api_period=20; 723 chan->wp_tdm_api_dev->cfg.usr_period=20; 724 chan->tdm_api_chunk=160; 725 chan->wp_tdm_api_dev->cfg.usr_mtu_mru=160; 726 } As I understand it, this chan->tdm_api_period=20 and chan->tdm_api_chunk=160 is the reason of 20ms increase interval measured in my tests. >> Finally, I tried to access the card more often than the default 20ms >> with default MTU:80 >> Since 80Bytes is 10ms, application was configured to read/write on >> 10ms rate with 80Bytes buffer. >> Following pseudocode ftdm_channel_read(fchan, bufferPtr, 80) failed >> with kernel error message in dmesg coming from wanpipe_tdm_api.c >> "User API Error: User Rx Len=144 < Driver Rx Len=224 (hdr=64). User >> API must increase expected rx length" >> Does it mean, that the smallest buffer used in the ftdm_channel_read() >> must be at least 160 B length even if MTU is 80 (or less) ? > > I suspect you changed the MTU to 80 but not the codec_ms to 10. If I > were you I'd stop messing around with the MTU unless you're willing to > look at the Wanpipe driver code. Not all values are meant to work for > all hardware and there are many types of hardware and many modes (API > mode, span mode, DAHDI mode etc) that can get complex to get right. > > Setting MTU to 80 (the default for TDM API mode) and codec_ms to 10 > you should not have latency bigger than 10ms. If you do, there is > something wrong with your app. The best I achieved with MTU:80 was by using txqueue_size=1 and this resulted in 60ms one-direction latency. Results were the same with wanpipe-3.5.20 and wanpipe-3.5.23. With best regards Juraj Fabo > > Moises Silva > Senior Software Engineer, Software Development Manager > Sangoma Technologies Inc. | 100 Renfrew Drive, Suite 100, Markham ON > L3R 9R6 Canada > t. 1 905 474 1990 x128 | e. moy(a)sangoma.com

1 1

A Chance To "Give Back" To FreeSWITCH
by Michael Collins 27 Sep '11

27 Sep '11

Hello all, I have a few FreeSWITCH-related projects with which I could use a hand. We have some non-glamorous janitorial items that need some attention. Specifically I could use assistance with a few freeswitch.org and wiki.freeswitch.org items. Some research/digging for answers is involved. If you have PHP skills those are a plus. Please email me off list if you are able to devote a few hours to some projects that I have pending. We will also discuss some of these on the FreeSWITCH conference call tomorrow. Thanks for giving back <http://www.freeswitch.org/node/339>. -Michael Collins

1 0

MTU setting and application buffer size
by Juraj Fabo 22 Sep '11

22 Sep '11

Hi, I'm writing and application using freetdm library and also a testtool which works as a loopback for voice data on B channels. Server A is running the loopback test tool is with a104d sangoma card configured in NET mode simulating telko infrastructure, clock on each span set to MASTER. Server B is running target aplication with 2 a102de cards configured in CPE mode and clock on each span is set to NORMAL. Spans of two serversSpans are connected with E1 cables, both servers running in sles11 sp1. Target application is reading/writing from/to another network stack A-law data with 20ms frame length. With default MTU settings (80) I am experiencing latency which I consider too high, it is about 400ms from targetApp to loopback and back to targetApp. I think I missed some point about proper setting of MTU and consequences. Decreasing the MTU configuration setting in the /etc/wanpipe/wanpipe1.conf from default value 80 to e.g 40 or 16 leads to desired lower latency, however, the data the targetApp is reading are often corrupted with many gaps. Please, what is the proper way of setting MTU? I assume I have to set the same MTU per wXg1 sections in /etc/wanpipe/wanpipeX.conf files on both servers, since the serverA card is providing a clock for server B cards. Is it necessary to change the value of codec_ms in the /usr/local/freetdm/conf/wanpipe.conf ? I also noticed following behaviour of ifconfig: a. MTU set to 40 or higher in section w1g1 in wanpipe1.conf also all other spans of the card which has the w1g1 (so w2g1 for the dualspan and w2g1, w3g1,w4g1 for quad card) will be displayed in ifconfig output with MTU: 40 b. MTU set to 80 or higher (e.g. 160) in section w1g1 in wanpipe1.conf ifconfig will display MTU:80 also for higher values Finally, I tried to access the card more often than the default 20ms with default MTU:80 Since 80Bytes is 10ms, application was configured to read/write on 10ms rate with 80Bytes buffer. Following pseudocode ftdm_channel_read(fchan, bufferPtr, 80) failed with kernel error message in dmesg coming from wanpipe_tdm_api.c "User API Error: User Rx Len=144 < Driver Rx Len=224 (hdr=64). User API must increase expected rx length" Does it mean, that the smallest buffer used in the ftdm_channel_read() must be at least 160 B length even if MTU is 80 (or less) ? Thank you very much Juraj

2 1

Outstanding Patches
by Kurtis Heimerl 16 Sep '11

16 Sep '11

Hello Freeswitch-dev! I have two outstanding patches sitting in JIRA. FS-3467 and FS-3408. They've been there for over a month, without any movement (so far as I can see). Is there anything else I'm supposed to be doing to get these moved into the main repository? Some code-review process? I don't want to have to maintain patches for such a fast-moving project. Thanks!

2 5

Re: [Freeswitch-dev] Linking to switch_json
by Phil Dunks 15 Sep '11

15 Sep '11

Thanks. I was running and compiling FS on my mac, which seemed to be the cause of this issue. I have now installed a Centos VM, and the problem has gone away. Cheers Phil, NetDev On 13 Sep 2011, at 13:28, freeswitch-dev-request(a)lists.freeswitch.org wrote: > > > From: Anthony Minessale <anthony.minessale(a)gmail.com> > Date: 13 September 2011 00:46:29 GMT+01:00 > To: freeswitch-dev(a)lists.freeswitch.org > Subject: Re: [Freeswitch-dev] Linking to switch_json > Reply-To: freeswitch-dev(a)lists.freeswitch.org > > > try building the .c into your mod too on the target list. > > > On Mon, Sep 12, 2011 at 12:43 PM, Phil Dunks <phil.dunks(a)netdev.co.uk> wrote: >> >> Hi FreeSWITCH Guru's. >> Apologies in advance for silly question - I've been coding Java for last 15 >> years, so the C is not coming naturally yet. >> Met some of you at ClueCon 2011 - had a great time - defeated Ken Rice at >> pool in the Lucky Strike - (OK I was lucky). >> We have a conferencing customer who is currently using JAIN SLEE and Radisys >> (Convedia) media servers. >> We are exploring the possibility of replacing all this with FS. >> They have a multi-tier account structure with provisionable preferences (e.g >> they can have different DTMF menu's and conference behaviour per >> account/subscription). >> So I have built a mod, which bridges our business logic with mod_conference. >> This is all working very well, and I love developing on FS compared to JAIN >> SLEE. >> So that's the background - here's the problem I'm having. >> I am trying to implement some JSON reporting, which we send over rabbit MQ, >> and am trying to use the cJSON api in switch_json directly from my mod. >> ( I have written a couple of mods [mod_rabbit_send and mod_rabbit_recv] >> which send and receive rabbit MQ events, and convert them to/from FS custom >> events. It uses a MPL library from rabbit.org. Will be happy to contribute >> them to the project if you want them. ). >> I include switch_json.h in my mod, and the cJSON stuff compiles and installs >> ok. >> But when I install the mod I get.. >> 2011-09-12 17:56:49.195659 [CRIT] switch_loadable_module.c:928 Error Loading >> module /usr/local/freeswitch/mod/mod_netdev.so >> **dlopen(/usr/local/freeswitch/mod/mod_netdev.so, 6): Symbol not found: >> _cJSON_AddItemToObject >> Referenced from: /usr/local/freeswitch/mod/mod_netdev.so >> >> I have tried all sorts of things in my makefile to get this linking - to no >> avail - I'm out of ideas. >> >> Any help will be greatly appreciated. >> Thanks >> Phil >> >> >> >> >> >> Phil Dunks >> NetDev Limited >> +44 1273 773661 >> +44 7515 385465 >> http://www.netdev.co.uk >> > Phil Dunks NetDev Limited +44 1273 773661 +44 7515 385465 http://www.netdev.co.uk Registered in England and Wales Company Number 04741258 Registered Office Address: 1st Floor, 47 Middle Street Brighton, East Sussex BN1 1AL, U.K.

1 0

FreeSWITCH Community Conference Call Today
by Michael Collins 14 Sep '11

14 Sep '11

Hello all! Today's agenda is here: http://wiki.freeswitch.org/wiki/FS_weekly_2011_09_14 We have Dave Kompel (resident Windows hacking guru) to talk to us about NuGet. He's also found a possible new solution for our build/test challenges. -MC

1 0

typo in the last commit?
by Seven Du 14 Sep '11

14 Sep '11

Hi, I see two SAF_ZOMBIE_EXEC in the last commit: http://fisheye.freeswitch.org/changelog/freeswitch.git/?cs=637a5ed83d73fbe2… 3927 SAF_SUPPORT_NOMEDIA | SAF_ROUTING_EXEC | SAF_ZOMBIE_EXEC | SAF_ZOMBIE_EXEC); -- About: http://about.me/dujinfang Blog: http://www.dujinfang.com Proj: http://www.freeswitch.org.cn Sent with Sparrow (http://www.sparrowmailapp.com)

2 2

SOLVED - Compile issue on ubuntu
by jay binks 13 Sep '11

13 Sep '11

I was getting compile time issues on ubuntu ( only as of todays git pull though... which is strange ) src/switch_core.c: In function ‘switch_system_fork’: src/switch_core.c:2405: error: ignoring return value of ‘system’, declared with attribute fixed it by making like 2405 of switch_core.c if ( system(cmd) ) {}; seems related to https://wiki.ubuntu.com/CompilerFlags error: ignoring return value of 'int system(const char*)', declared with attribute warn_unused_result The return value from system(), write(), and similar functions should be evaluated and handled appropriately. In cases where one absolutely must throw away the return value, it can be discarded with an empty test: if (system("...")) { } , though this is not recommended. maybe a better solution would be to change compiler flags... not sure... just letting someone smarter than me know about it :) -- Sincerely Jay

1 0