[libnice] Pseudotcp performance (with focus on Windows)

Philip Withnall philip at tecnocode.co.uk
Sun Jul 6 05:49:27 PDT 2014


On Fri, 2014-07-04 at 10:36 +0200, Radosław Kołodziejczyk wrote:

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

Thanks for looking at this in depth. Do you have any Wireshark logs of
the timeout occurring, coupled with libnice debug logs? Run your tests
with NICE_DEBUG=all G_MESSAGES_DEBUG=all environment variables set and
attach the resulting debug logs (making sure there is no private data in

> // 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?

As Olivier said, this is most likely due to packet loss. But perhaps
hitting a buggy case where the pseudotcp code doesn’t recover well from
a lost packet.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/nice/attachments/20140706/11bd1679/attachment.sig>

More information about the nice mailing list