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
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@gmail.com>
To: freeswitch-dev@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@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 ManagerSangoma Technologies
100 Renfrew Drive, Suite 100, Markham, ON L3R 9R6 Canada
t. +1 800 388 2475 (N. America)
Products | Solutions | Events | Contact | Wiki | Facebook | Twitter`| | YouTube
VegaStream is now part of Sangoma!
Ask us about both Gateway Appliances and Internal Gateways