[libnice] Pseudotcp performance (with focus on Windows)

[Radosław Kołodziejczyk]

Hello again,

I've made the link available for longer. I'll keep it up untill it's not
needed anymore. Please let me know if you'd need something more. I'll be
looking into this next week but it's always good to have insight especially
from the authors themselves.

Kind regards,
Radosław Kołodziejczyk.


2014-07-07 11:48 GMT+02:00 Radosław Kołodziejczyk <
radek.kolodziejczyk at gmail.com>:

> 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/20140715/85b9a4b8/attachment.html>