<div dir="ltr"><div>Hi Dario,</div><div><br></div><div>Increasing the buffering on the receive side will not change the average latency, but will allow for a higher peak latency.  The fact that increasing the buffering resolved the overflow issue indicates that the buffer was not being drained fast enough, which suggests that the application has excess latency between recv() calls.  This is commonly caused by the thread performing some sort of IO operation (such  as writing data to disk).</div><div><br></div><div>Regards,</div><div>Michael</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 8, 2015 at 10:18 AM, Dario Fertonani via USRP-users <span dir="ltr"><<a href="mailto:usrp-users@lists.ettus.com" target="_blank">usrp-users@lists.ettus.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I was able to eliminate the rare overflow errors just by using higher values of recv_frame_size and num_recv_frames for the rx stream. Our stack easily meet the timeline, so we're looking at eliminating rare overflow errors due to the non-deterministic nature of the non-real-time OS (in our case, Ubuntu 14.04 low latency), rather than to slow stack processing.</div><div><br></div>Any drawback in using high values of recv_frame_size and num_recv_frames, besides memory usage/waste? For example, I don't fully understand what happens when num_recv_frames is bumped up to 256 from the default value of 16. Does the worst-case latency increases by 16 times?<br><div><br></div><div>Thanks,</div><div>Dario</div></div>
<br>_______________________________________________<br>
USRP-users mailing list<br>
<a href="mailto:USRP-users@lists.ettus.com">USRP-users@lists.ettus.com</a><br>
<a href="http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com" target="_blank" rel="noreferrer">http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com</a><br>
<br></blockquote></div><br></div>