[libnice] Pseudotcp performance (with focus on Windows)

[Radosław Kołodziejczyk]

Hello,

I've redone the tests with wireshark monitoring the process and the
environment set the way you wanted. The 4s pause is clearly visible in
Wireshark dump. It's a regular thing - there's a couple of kBs sent, then a
4s pause and the transfer resumes in full speed after a 66B packet is
reveived by the client. Could that be a "missing" ACK? Anyway it seems that
this packet triggers further transfer and the agents are waiting for its
arrival.

Our test is a simple echo client-server pair that sends random data and
expect the exact data in return from server. I attach the Wireshark dump as
well as nice logs from client and server test programs. I'll be very
pleased to help debug / solve this issue so if you need anything more - I'm
here to help. :)

Btw I've cancelled my previous response, because the attachment was too
big. Instead I've uploaded it to my public dropbox space and you can get it
from here:

https://dl.dropboxusercontent.com/u/94203634/niceDebug.tar.gz

The link will be valid for a week.

Cheers!


2014-07-06 14:49 GMT+02:00 Philip Withnall <philip at tecnocode.co.uk>:

> Hi,
>
> 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
> them).
>
> > // 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.
>
> Philip
>
>
> _______________________________________________
> nice mailing list
> nice at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nice
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/nice/attachments/20140707/05541c21/attachment.html>