[libnice] Pseudotcp performance (with focus on Windows)

[Philip Withnall]

Hi,

Sorry for the delay in looking at this. Without the test programs, it’s
hard to reproduce and debug the issue. Can you make the test client and
server code available please?

That said, there have been several improvements to the pseudo-TCP code
in git master recently. Have you tried your tests again with the latest
git master of libnice?

Philip

On Tue, 2014-07-15 at 15:14 +0200, Radosław Kołodziejczyk wrote:
> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/nice/attachments/20140813/bd8e8ca5/attachment.sig>