<div dir="ltr">Hello again,<div><br></div><div>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.</div>
<div><br></div><div>Kind regards,</div><div>Radosław Kołodziejczyk.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-07-07 11:48 GMT+02:00 Radosław Kołodziejczyk <span dir="ltr"><<a href="mailto:radek.kolodziejczyk@gmail.com" target="_blank">radek.kolodziejczyk@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class=""><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">
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.</div>
<div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><br></div></div><div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">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. :)</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">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:</div>
<div style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><br></div><div><font color="#000000" face="arial, sans-serif"><a href="https://dl.dropboxusercontent.com/u/94203634/niceDebug.tar.gz" target="_blank">https://dl.dropboxusercontent.com/u/94203634/niceDebug.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">The link will be valid for a week.</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">Cheers!</div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="">2014-07-06 14:49 GMT+02:00 Philip Withnall <span dir="ltr"><<a href="mailto:philip@tecnocode.co.uk" target="_blank">philip@tecnocode.co.uk</a>></span>:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<div><div class="h5"><br>
<div><br>
On Fri, 2014-07-04 at 10:36 +0200, Radosław Kołodziejczyk wrote:<br>
<br>
<br>
> We moved forward a bit and digged in search for where the hiccups<br>
> occur. It seems that the data transfer is actually quite fast and<br>
> fluent, BUT every so often (by that I mean too often) there is a huge<br>
> gap between recv callbacks from agent. Exactly 4s gaps. This totally<br>
> kills the transfer rate as you might imagine. Exactly 4s seemed to be<br>
> "too perfect" to be accidental, so after a quick grep I found this:<br>
<br>
</div>Thanks for looking at this in depth. Do you have any Wireshark logs of<br>
the timeout occurring, coupled with libnice debug logs? Run your tests<br>
with NICE_DEBUG=all G_MESSAGES_DEBUG=all environment variables set and<br>
attach the resulting debug logs (making sure there is no private data in<br>
them).<br>
<div><br>
> // If there are no pending clocks, wake up every 4 seconds<br>
> #define DEFAULT_TIMEOUT 4000<br>
><br>
> 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?<br>
<br>
</div>As Olivier said, this is most likely due to packet loss. But perhaps<br>
hitting a buggy case where the pseudotcp code doesn’t recover well from<br>
a lost packet.<br>
<span><font color="#888888"><br>
Philip<br>
<br>
</font></span><br></div></div><div class="">_______________________________________________<br>
nice mailing list<br>
<a href="mailto:nice@lists.freedesktop.org" target="_blank">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></div></blockquote></div><br></div>
</blockquote></div><br></div>