[Freeswitch-dev] MTU setting and application buffer size

[Juraj Fabo]

Hi

thank you for your response.

Here is my code used for testing the latency http://pastebin.com/mwHrRDeK.
It is based on and built as freeswitch-git/libs/freetdm/src/testapp.c
For the measurement I used a104d card with interconnected spans 1&2.
App loads binary file "sample_binin" which was previously created by dumping
the E1 channel when there was active call.
This dump is used as a source of voice.
App initiates a call on span1. App handles it as incoming call on span2.

After call is established, measurement loop is entered,measurement is in
single thread world, handling the spans 1 & 2 in "serial".
App feeds prebuffered voice to outgoing call on span1 and in paralell makes
a dump of written data to binary file "owbinout".
At the same time, data read from the span1 are dumped to binary file
"orbinout".
Then span2 is handled, data read from the active channel are just written
back, here the loopback is created.
In paralell data are dumped to file "awbinout"

So then results are being calculated by comparing the content of :
owbinout against awbinout = one way delay
owbinout against orbinout = roundtrip delay

Personally I use Audacity to import the binary voice, decode it and pair in
stereotracks so I can measure the delay.

With this approach I got the results posted earlier.

With best regards

Juraj Fabo



> ---------- Forwarded message ----------
> From: Moises Silva <moises.silva at gmail.com>
> To: freeswitch-dev at lists.freeswitch.org
> Date: Mon, 17 Oct 2011 12:22:58 -0400
> Subject: Re: [Freeswitch-dev] MTU setting and application buffer size
> On Tue, Oct 4, 2011 at 8:56 AM, Juraj Fabo <juraj.fabo at gmail.com> wrote:
>
>> > 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
>> >
>>
>>
>> Updated test result with the codec_ms=10 is following:
>> mtu:16 txqueue_size=1  rxqueue_size=10   one-direction delay=20ms
>> round-trip delay=50ms
>> mtu:80 txqueue_size=1  rxqueue_size=10   one-direction delay=56ms
>> round-trip delay=110ms
>>
>> However, this is still not 10ms with the default MTU:80 and codec_ms:10 :(
>>
>> Anyway, is it a good idea to use so assymetric tx/rx queue sizes?
>>
>>
> In general I don't think is a good idea because 99% of the user population
> is using default symmetric queues, moving to obscure/rarely-tested
> configurations increases your likelihood of facing problems. Having said
> that, I don't see why it should not work :-)
>
> Can you share the code you're using to measure latency? may be setup a git
> repo in github with your code?
>
>  *Moises Silva
> **Software Engineer, Development Manager***
>
> msilva at sangoma.com
>
> Sangoma Technologies
>
> 100 Renfrew Drive, Suite 100, Markham, ON L3R 9R6 Canada
>
>
> t.   +1 800 388 2475 (N. America)
>
> t.   +1 905 474 1990 x128
>
> f.   +1 905 474 9223
>
>
>
> **<http://www.sangoma.com/contact?utm_source=signature&utm_medium=email&utm_campaign=email+signatures>
>
> Products<http://sangoma.com/products?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures>
>  | Solutions<http://sangoma.com/solutions?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures>
>  | Events<http://sangoma.com/about_us/events?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures>
>  | Contact<http://www.sangoma.com/contact?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures>
>  | Wiki<http://wiki.sangoma.com/?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures>
>  | Facebook<http://www.facebook.com/pages/Sangoma-VoIP-Cards/43578453335?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures>
>  | Twitter<http://www.twitter.com/sangoma?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures>`|
> | YouTube<http://www.youtube.com/sangomatechnologies?utm_source=signature&utm_medium=email&utm_campaign=email%2Bsignatures>
>
>                 VegaStream is now part of Sangoma!<http://sangoma.com/about_us/newsroom/news_releases/news/1488795/Sangoma_Acquires_All_Key_Assets_of_VegaStream.html>
>
>                 Ask us about both Gateway Appliances<http://sangoma.com/products/media_gateways/vega.html>
>  and Internal Gateways<http://sangoma.com/products/software_products/netborder_suite/netborder_express.html>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20111023/bd69ca6c/attachment.html