[Freeswitch-dev] MTU setting and application buffer size

[Moises Silva]

On Mon, Sep 19, 2011 at 12:30 PM, Juraj Fabo <juraj.fabo at 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).

> 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.

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 at sangoma.com