[USRP-users] recv_frame_size and num_recv_frames for B210

Michael West michael.west at ettus.com
Thu Jul 9 12:27:58 EDT 2015


Hi Dario,

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).

Regards,
Michael

On Wed, Jul 8, 2015 at 10:18 AM, Dario Fertonani via USRP-users <
usrp-users at lists.ettus.com> wrote:

> 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.
>
> 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?
>
> Thanks,
> Dario
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150709/a4e373ec/attachment-0002.html>


More information about the USRP-users mailing list