<div dir="ltr"><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">Hello,</span><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><br></div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">
Our test programs are made of our libraries wrapped around <span>libnice</span> so it would</div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">not be easy to send this for you to test. We did, however, discover something</div>
<div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">new that should make it easier to investigate. As we were preparing a</div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">
test that we could send you to verify the problem we noticed that when the program</div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">consists only of client and server, when client's only job is to send data which</div>
<div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">server receives and dumps, the transfer is actually really good. Comparable with</div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">
TCP even (on some machines, some still have speed issue, but not that</div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">great). However, when you add a case where server behaves as a echo machine</div>
<div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">(not even that - it suffices for server to respond with even small 4B packets)</div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">
the transfer goes down by great amount. These are our observations on our most</div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">problematic machine:</div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">
<br></div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">Program specs:<br>CLIENT - sends 32 kB in loop</div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">SERVER - receives the message, ignores it.</div>
<div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><br></div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">Average transfer: ~1MB</div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">
<br></div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">Program specs:</div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">CLIENT - sends 32 kB in loop<br> - waits for 4B response.<br>
<br>SERVER - receives 32 kB message</div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"> - sends 4B response.</div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">
<br></div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">Average transfer: 10-70 KB/s</div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><br></div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">
All of this is done on localhost so even the first transfer is not that spectacular, but</div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">it's much, much better than what we have with the two-side sending. So maybe that</div>
<div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">could be some clue.</div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><br></div><div style>
<div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">Speaking of your latest code from git master - we've some issues with connecting</div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">
the agents on system where 0.1.7 version connected without any issues. On Windows<br></div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">XP the problem was for both reliable and unreliable agents. On 7 only reliable agents</div>
<div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">had problem connecting. My colleague prepared a package with logs from successfull</div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">
connect on 0.1.7 and unsuccessfull on the code from git. I know it is not yet an</div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">official release, but we thought you might find it interresting or it might help you</div>
<div style><font color="#000000" face="arial, sans-serif">in development. Here it is:</font><br><br><font color="#000000" face="arial, sans-serif"><a href="https://dl.dropboxusercontent.com/u/94203634/2014-08-01_nice_logs.tar.gz">https://dl.dropboxusercontent.com/u/94203634/2014-08-01_nice_logs.tar.gz</a></font><br>
</div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><br></div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">Kind regards,</div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">
Radosław Kołodziejczyk</div></div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><br></div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">
<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-08-13 1:31 GMT+02:00 Philip Withnall <span dir="ltr"><<a href="mailto:philip@tecnocode.co.uk" target="_blank">philip@tecnocode.co.uk</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Sorry for the delay in looking at this. Without the test programs, it’s<br>
hard to reproduce and debug the issue. Can you make the test client and<br>
server code available please?<br>
<br>
That said, there have been several improvements to the pseudo-TCP code<br>
in git master recently. Have you tried your tests again with the latest<br>
git master of libnice?<br>
<span class="HOEnZb"><font color="#888888"><br>
Philip<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Tue, 2014-07-15 at 15:14 +0200, Radosław Kołodziejczyk wrote:<br>
> Hello again,<br>
><br>
><br>
> I've made the link available for longer. I'll keep it up untill it's<br>
> not needed anymore. Please let me know if you'd need something more.<br>
> I'll be looking into this next week but it's always good to have<br>
> insight especially from the authors themselves.<br>
><br>
><br>
> Kind regards,<br>
> Radosław Kołodziejczyk.<br>
><br>
><br>
> 2014-07-07 11:48 GMT+02:00 Radosław Kołodziejczyk<br>
> <<a href="mailto:radek.kolodziejczyk@gmail.com">radek.kolodziejczyk@gmail.com</a>>:<br>
> Hello,<br>
><br>
><br>
> I've redone the tests with wireshark monitoring the process<br>
> and the environment set the way you wanted. The 4s pause is<br>
> clearly visible in Wireshark dump. It's a regular thing -<br>
> there's a couple of kBs sent, then a 4s pause and the transfer<br>
> resumes in full speed after a 66B packet is reveived by the<br>
> client. Could that be a "missing" ACK? Anyway it seems that<br>
> this packet triggers further transfer and the agents are<br>
> waiting for its arrival.<br>
><br>
><br>
> Our test is a simple echo client-server pair that sends random<br>
> data and expect the exact data in return from server. I attach<br>
> the Wireshark dump as well as nice logs from client and server<br>
> test programs. I'll be very pleased to help debug / solve this<br>
> issue so if you need anything more - I'm here to help. :)<br>
><br>
><br>
> Btw I've cancelled my previous response, because the<br>
> attachment was too big. Instead I've uploaded it to my public<br>
> dropbox space and you can get it from here:<br>
><br>
><br>
> <a href="https://dl.dropboxusercontent.com/u/94203634/niceDebug.tar.gz" target="_blank">https://dl.dropboxusercontent.com/u/94203634/niceDebug.tar.gz</a><br>
><br>
><br>
><br>
> The link will be valid for a week.<br>
><br>
><br>
> Cheers!<br>
><br>
><br>
> 2014-07-06 14:49 GMT+02:00 Philip Withnall<br>
> <<a href="mailto:philip@tecnocode.co.uk">philip@tecnocode.co.uk</a>>:<br>
><br>
> Hi,<br>
><br>
><br>
> On Fri, 2014-07-04 at 10:36 +0200, Radosław<br>
> Kołodziejczyk wrote:<br>
><br>
><br>
> > We moved forward a bit and digged in search for<br>
> where the hiccups<br>
> > occur. It seems that the data transfer is actually<br>
> quite fast and<br>
> > fluent, BUT every so often (by that I mean too<br>
> often) there is a huge<br>
> > gap between recv callbacks from agent. Exactly 4s<br>
> gaps. This totally<br>
> > kills the transfer rate as you might imagine.<br>
> Exactly 4s seemed to be<br>
> > "too perfect" to be accidental, so after a quick<br>
> grep I found this:<br>
><br>
><br>
> Thanks for looking at this in depth. Do you have any<br>
> Wireshark logs of<br>
> the timeout occurring, coupled with libnice debug<br>
> logs? Run your tests<br>
> with NICE_DEBUG=all G_MESSAGES_DEBUG=all environment<br>
> variables set and<br>
> attach the resulting debug logs (making sure there is<br>
> no private data in<br>
> them).<br>
><br>
> > // If there are no pending clocks, wake up every 4<br>
> seconds<br>
> > #define DEFAULT_TIMEOUT 4000<br>
> ><br>
> > And sure - tinkering with this value provided<br>
> different transfer speeds (sometimes much, much higher<br>
> - almost on par with tcp). Of course changing this<br>
> default timeout should not be a solution. So my<br>
> question is - what may cause a scenario when this<br>
> timeout is reached really frequently and do you have<br>
> any idea how to improve to avoid it?<br>
><br>
><br>
> As Olivier said, this is most likely due to packet<br>
> loss. But perhaps<br>
> hitting a buggy case where the pseudotcp code doesn’t<br>
> recover well from<br>
> a lost packet.<br>
><br>
> Philip<br>
><br>
><br>
><br>
> _______________________________________________<br>
> nice mailing list<br>
> <a href="mailto:nice@lists.freedesktop.org">nice@lists.freedesktop.org</a><br>
> <a href="http://lists.freedesktop.org/mailman/listinfo/nice" target="_blank">http://lists.freedesktop.org/mailman/listinfo/nice</a><br>
><br>
><br>
><br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>