Re: [Freeswitch-dev] MTU setting and application buffer size
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? with best regards Juraj
On Tue, Oct 4, 2011 at 8:56 AM, Juraj Fabo <juraj.fabo@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@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>
participants (2)
-
Juraj Fabo
-
Moises Silva