[libnice] Pseudotcp performance (with focus on Windows)

[Radosław Kołodziejczyk]

Hello again,

We moved forward a bit and digged in search for where the hiccups occur. It
seems that the data transfer is actually quite fast and fluent, BUT every
so often (by that I mean too often) there is a huge gap between recv
callbacks from agent. Exactly 4s gaps. This totally kills the transfer rate
as you might imagine. Exactly 4s seemed to be "too perfect" to be
accidental, so after a quick grep I found this:

// If there are no pending clocks, wake up every 4 seconds
#define DEFAULT_TIMEOUT 4000


And sure - tinkering with this value provided different transfer
speeds (sometimes much, much higher - almost on par with tcp). Of
course changing this default timeout should not be a solution. So my
question is - what may cause a scenario when this timeout is reached
really frequently and do you have any idea how to improve to avoid it?


Thanks for your time. Kind regards,

Radosław Kołodziejczyk.



2014-06-17 18:17 GMT+02:00 Olivier Crête <olivier.crete at collabora.com>:

> Hi,
>
> On Tue, 2014-06-17 at 13:44 +0200, Radosław Kołodziejczyk wrote:
> > Hello,
> >
> > We've compiled libnice and are using it with GLIB 2.34 on Windows to
> > transfer data using the reliable agent. What we found is that it can
> > have a really poor performance on some hosts. We've put together a
> > simple test program to send gibberish from client to server and even
> > while running it via LAN the transfer rate on some systems is down to
> > 0,5 MB/s. We can observe 'hiccups' on the receiving side, where the
> > data callback is not being called for periods of 100-400 ms sometimes.
> > I see a lot of retransmits going on on the sending side.
> >
> > Does anyone have any experience with the reliable agent, especially on
> > Windows, and may provide some insight what can be tweaked or what can
> > cause such issues?
>
> Most of these are probably due to packet losses, the pseudotcp code is
> quite primitive in that regard.
>
> --
> Olivier Crête
> olivier.crete at collabora.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/nice/attachments/20140704/898917e8/attachment-0001.html>