[Freeswitch-dev] MTU setting and application buffer size

[Moises Silva]

On Tue, Oct 4, 2011 at 8:56 AM, Juraj Fabo <juraj.fabo at gmail.com> wrote:

> Hi,
>
> I read through the previous answers several times again and did some
> progress.
> I found out that the valid codec_ms values are <10ms,60ms> and using lower
> values will not work.
>
> >> 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().
> >>
> >>
> >> 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()).
> >>
>
> In each of the the test below the codec_ms was set to 1 with hope
> of fastest data delivery, however this resulted to 20ms codec_ms
> which is default.
>
>
> > 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/20111017/47d996e8/attachment-0001.html